free (NULL)

Boyd Roberts boyd at necisa.ho.necisa.oz
Wed May 30 09:55:42 AEST 1990


In article <3078 at goanna.cs.rmit.oz.au> ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
|
|The problem I've often had is that I have a data structure containing
|some pointers, and *I* have filled some of them in (using strdup())
|and the caller preset some of them to defaults.  Now I'm going to change
|one of them.  Should I free it?  If *I* allocated it, certainly, there
|isn't any other copy of the pointer.  If the *caller* allocated it
|*and* the caller hasn't any other copy of the pointer *and* it was
|allocated using malloc() then it would be a good idea to free it, but
|if	-- the caller wants to keep it
|or	-- it was a string literal
|or	-- it came from something other than malloc()
|then it should _not_ be given to free(), and checking for NULL isn't
|going to help me.  I've been driven to two extremes, neither of which

Well, once you've coded yourself into a corner all bets are off.  Choose
a better algorithm, one that has all the pointers in a free-able state.

The general case of `should I free this thing returned by a library routine'
is handled by RTFM.  TFM should state what storage class the object returned
is.  If it's malloc()'d it should then also be clear whether the object is
free()'d by a companion function `finished_with_this_thing(p)', or whether
it is safe to just free() it.

I can't see there's much of a problem with the standard libraries.


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

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



More information about the Comp.lang.c mailing list