free (NULL)

[Boyd Roberts]

In article <2574 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes: >
>*Sigh*  Yes, *if* you allocate something, you probably want to free it
>later.  But what if you *didn't* allocate it?  Then you *don't* want
>to free it.
>

Yeah, right...

>
>If the NULL you pass to free was handed to you by malloc() than you
>should almost certainly have already checked for it.  Even in this
>case, it may simplify your error cleanup code if you just call free()
>anyway.  But this wasn't one of the situations I had in mind.
>

And now you want to free the unallocated object, courtesy of certain
implementations' blessing on the construct free(NULL).

The bottom line is that the library should not be mangled to cater
for sloppy programming practices, which are deemed to be convenient.
When I see a C library I expect it to address itself to the precise
problem at hand and nothing more.  I don't want code in there that
checks that it's a Tuesday and that it's statistically likely that
on Tuesdays a certain class of programmers will make certain wrong
assumptions and the code will correct it.

The onus is on the programmer to write correct programs.  It should
not be the library's job to act as a safety net for these `conveniences'.


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

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