Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!samsung!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.lang.c
Subject: Re: free (NULL)
Message-ID: <1743@necisa.ho.necisa.oz>
Date: 31 May 90 23:11:06 GMT
References: <1771@mindlink.UUCP> <NUG33GF@xds13.ferranti.com> <2574@skye.ed.ac.uk> <1739@necisa.ho.necisa.oz> <3103@goanna.cs.rmit.oz.au>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 30

In article <3103@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>
>Whether something is freeable is NOT a property of the algorithm which has
>to make the immediate decision.  It is a property of the program that USES
>the algorithm.  If you're writing a library function, you simply haven't
>any control over the code that uses your function.
>

Exactly, you don't have control over what your caller does.  That's not
your problem, it's the caller's.

The issue is in defining an _interface_.  If it's ill or badly defined
then you've got major problems.  A library routine must have a well defined
_interface_.  The caller is bound to abide by the interface.  If the
caller doesn't, the routine will have its revenge (thanks Henry).

The library routine should state that the objects returned are either:

   1. Static and should not be free()'d.

   2. malloc()'d and should be free()'d by the caller.

   3. Allocated and cleaned up by a finished_with_this_object(p) call.

Those are the choices.  If you don't play by the rules, all bets are off.


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''