Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <10990@smoke.BRL.MIL>
Date: 9 Sep 89 01:05:01 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM> <248@seti.inria.fr> <10817@riks.csl.sony.co.jp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11

In article <10817@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
>Well, because a freed pointer is still valid in a call to realloc
>(as long as there are no intervening *alloc calls), ...

Nope.  That guarantee that you've read in some MALLOC(3) UNIX manual
page, was documenting an arguably useful feature of a particular
implementation.  There have been malloc/free/realloc implementations
for many years that had no such guarantee, and X3J11 were not convinced
that there was sufficient need for such a guarantee to justify the
heavy implementation constraints imposed by it.  Therefore the Standard
makes realloc(free(ptr),size) explicitly undefined behavior.