Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!mcsun!hp4nl!philapd!ssp1!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <246@ssp1.idca.tds.philips.nl>
Date: 7 Sep 89 09:20:05 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>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 30

In article <248@seti.inria.fr> jourdan@minos.inria.fr (Martin Jourdan) writes:
->In article <16022@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
->>bill@twwells.com (T. William Wells) writes:
->>> ...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.
->>Not true.  The "if" only examines the value of the pointer, not what it
->>points to.
->You're wrong, Dick.  Someone else already pointed it out, but let me
->make it clear again.  Imagine a segmented memory architecture with
->protections, and imagine that the call to "free" above frees the last
->used block in the segment and that "free" is clever enough to
->determine it and decides to release the segment to the OS, thus making
->the whole segment invalid [...]
-> [...].  Then merely loading the value of "ptr" in a register to test it
->against 0 will cause a invalid-address trap.

I agree with Dick, as the original statement is:
   if (ptr == 0) ...
I think Martin explained why the statement:
   if (*ptr == 0) ...
is unacceptable and how the OS could trigger this illegal use.
Is this true or am I missing Martin's point ?
-- 
Dolf Grunbauer          Tel: +31 55 432764  Internet dolf@idca.tds.philips.nl
Philips Telecommunication and Data Systems  UUCP ....!mcvax!philapd!dolf
Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands