Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!ti-csl!tilde.csc.ti.com!pearl!pearl!mikep From: mikep@dirty.csc.ti.com (Michael A. Petonic) Newsgroups: comp.lang.c Subject: Re: Life after free? Message-ID: Date: 2 Oct 90 10:13:40 GMT References: <5620@stpstn.UUCP> <18339@haddock.ima.isc.com> Sender: news@pearl.dsg.ti.com (System News Administration) Distribution: comp Organization: Texas Instruments, Speech Mushrooms. Lines: 26 In-Reply-To: karl@haddock.ima.isc.com's message of 29 Sep 90 07:02:45 GMT In article <18339@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <5620@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: >>In article quan@sol.surv.utas.oz (Stephen Quan) writes: >>->Any comments on free-ing tmp before it is return-ed? >> >>Not only is it sensible, the semantics of free require it. > >No. An early manual once made the mistake of describing the local >implementation instead of the interface%, but not all versions do it that >way. Some modern systems still include such a guarantee, but only to provide >backward compatibility to the programs that were foolish enough to depend on >it. The Standard doesn't even guarantee that you can *look* at the value >remaining in tmp, much less dereference it. > >Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint In K&R (1st edition), malloc() isn't a feature of the language, it's a library call. So -- I guess it would have to depend on the library's implementation, wouldn't it? In UNIX V.3, malloc(3C) (ie, the freemalloc() function contained within libc) is defined to have a free() which leaves the contents of the freed memory undisturbed. But in libmalloc, free(3X) is defined to destroy the contents of the freed memory. -MikeP