Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: free (NULL) Message-ID: <3124@goanna.cs.rmit.oz.au> Date: 1 Jun 90 03:12:12 GMT References: <1771@mindlink.UUCP> <2574@skye.ed.ac.uk> <1743@necisa.ho.necisa.oz> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 27 In article <1743@necisa.ho.necisa.oz>, boyd@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."