Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!husc6!cmcl2!stealth.acf.nyu.edu!brnstnd
From: brnstnd@stealth.acf.nyu.edu
Newsgroups: comp.lang.c
Subject: Re: free (NULL)
Message-ID: <270:Jun113:33:1590@stealth.acf.nyu.edu>
Date: 1 Jun 90 13:33:15 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> <3466:May3022:56:1890@stealth.acf.nyu.edu> <9YT3MP@xds13.ferranti.com>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Organization: IR
Lines: 25

In article <9YT3MP@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> In article <3466:May3022:56:1890@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
> > 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.'')
> I disagree with this entirely. If you return a variable amount of data to
> your parent, there are two ways to go about it.
  [ 1. like read() ]
  [ 2. like fopen()/fclose() ]

read() falls under the ``provide enough information to your callers that
they can allocate for you.'' The way fopen() and fclose() allocate FILEs
falls under the sentence you left out: ``If you do need to keep
allocated memory around between calls, only use that space internally;
don't pass it up to your parent.'' (The pointer that fopen() passes up
isn't defined as a pointer to malloc()ed space, isn't always such a
pointer, and may not be dereferenced or freed portably; perhaps I should
have said ``don't tell your parent how to find or use the space.'')

So what are you disagreeing with? I don't think I'm totally off base,
because Boyd Roberts made the same three-way classification in a
simultaneous article.

---Dan