Life after free?

[Michael A. Petonic]

In article <18339 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
>In article <5620 at stpstn.UUCP> lerman at stpstn.UUCP (Ken Lerman) writes:
>>In article <quan.654410256 at sol> quan at 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 at 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