Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!dali!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!stealth.acf.nyu.edu!brnstnd
From: brnstnd@stealth.acf.nyu.edu
Newsgroups: comp.lang.c
Subject: Re: free (NULL)
Message-ID: <3466:May3022:56:1890@stealth.acf.nyu.edu>
Date: 30 May 90 22:56:18 GMT
References: <1771@mindlink.UUCP> <NUG33GF@xds13.ferranti.com> <2574@skye.ed.ac.uk> <1074:May3000:24:1990@stealth.acf.nyu.edu> <3102@goanna.cs.rmit.oz.au>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Organization: IR
Lines: 24

In article <3102@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> In article <1074:May3000:24:1990@stealth.acf.nyu.edu>, brnstnd@stealth.acf.nyu.edu writes:
    [ some general comments on how to deal with the multiple-pointer ]
    [ freeing problem ]
> This doesn't quite address my problem.

Well, what about my last paragraph, which says what I do in practice?
Namely: Whatever you allocate inside a routine, you also deallocate
inside that routine. If your memory needs are variable, provide enough
information to your callers that they can allocate for you. (This is
called ``passing the buck.'') If you do need to keep allocated memory
around between calls, only use that space internally; don't pass it up
to your parent.

> My real
> problem is how can I write library packages so that it is easy for
> *other* people using them to follow whatever protocol is necessary.

UNIX library routines generally either require the caller to provide a
pointer to the result, or keep the information in a static area that's
erased on each call. Both cases match the ``deallocate what you
allocate'' philosophy.

---Dan