free (NULL)

[Richard A. O'Keefe]

In article <1743 at necisa.ho.necisa.oz>, boyd at necisa.ho.necisa.oz (Boyd Roberts) writes:
> 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.

Somewhere the context seems to have been lost.  I wasn't talking about
library routines to create single objects, but library routines to manage
a collection of objects (think of hsearch and the like) where the objects
     4. Are sometimes things that the caller provided (whatever they are)
        and sometimes things that the package mallocked
I mean, I'm talking about something that may be given hundreds of default
"objects", and just change one or two.  Copying _everything_ so that
everything would deserve freeing is obviously not a nice thing.  C++
would in effect tag each of the strings or other default objects with
its own deallocation routine, but it still would not be appropriate for
the collection maintenance routines to "destroy" objects that _they_
didn't "new".

    Basically, the problem is that a mathematically clean interface design
can sometimes be made much more complicated if your language does not
support automatic storage management.  Oh well, if I want Scheme I know
where to find it.
-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."