Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.csd.uwm.edu!mailrus!ncar!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.lang.c Subject: Re: effect of free() Summary: def'n of free() has changed Message-ID: <16020@vail.ICO.ISC.COM> Date: 17 Aug 89 22:50:38 GMT References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> Organization: Interactive Systems Corp, Boulder, CO Lines: 25 > : I guess the word is, once space is freed, don't even try to get data > : out of it. It's risky at least, and nonportable without question. The definition of free() has changed - I think for the better, but suffice it that old code may have assumptions of the old behavior. In V7, Sys III, and BSD, the definition of free() explicitly provided that the storage was released but would remain intact and in place until the next malloc call. I'm not sure just what all this might allow, but one example is a slight simplification of freeing a singly-linked structure: for (p=head; *p; p=p->next) free(p); without needing two pointers. (Note that the increment picks the "next" field out of a freed struct.) In Sys V.3.2, the default behavior of free destroys the block of freed storage, but it can be modified to have the old behavior for compatibility reasons. Such usage is, of course, discouraged. ANSI C makes no provision for the old behavior. Seems just as well to let it die. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Are you making this up as you go along?