Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!mimir!hugin!augean!idall
From: idall@augean.OZ (Ian Dall)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <568@augean.OZ>
Date: 18 Aug 89 07:37:31 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU>  <320@cubmol.BIO.COLUMBIA.EDU> <3777@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com>
Organization: Engineering Faculty, University of Adelaide, Australia
Lines: 38
Reply-To:

In article <1989Aug17.005548.745@twwells.com> bill@twwells.com (T. William Wells) writes:
-In article <3777@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
-: In article <320@cubmol.BIO.COLUMBIA.EDU> ping@cubmol.UUCP (Shiping Zhang) writes:
-: 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.
-
-Actually, things are worse than that: once the space is freed, don't
-even *look* at the pointer. For example, the following code fragment
-is nonportable:
-
-	char    *ptr;
-
-	ptr = malloc(1);
-	...
-	free(ptr);
-	...
-	if (ptr == 0) ...
-
-The if might cause a trap when the value of ptr is accessed.

Well you should strictly do something like 

      if (ptr == (char *) 0) ...

If that causes a trap your compiler and/or operating system is
definitely broken. Ptr is just a local variable and you can compare it
with anything of the appropriate type (a pointer to a char). Free does
not (and cannot since C is call by value) alter the quantity in ptr.
Free DOES make *ptr meaningless but not ptr.

The compiler doesn't know what malloc and free do. For all the
compiler knows malloc and free could be functions you wrote with
completely different semantics.

-- 
 Ian Dall           life (n). A sexually transmitted disease which afflicts
                              some people more severely than others.
idall@augean.oz