Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <1524@cbnewsl.ATT.COM>
Date: 18 Aug 89 14:17:23 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 34

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:
>> 
>> 	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.  free(ptr) does not modify ptr; it can't.  Assuming the malloc
>succeeded (and assuming an appropriate in-scope declaration of malloc, if
>you want to be fussy), the code as written will work, and the body of the
>"if" will not be executed, since ptr will be non-null from the malloc.
>
>The trouble will only begin when you try to look at *ptr.

Not according to the pANS.

Section 4.10.3, page 155, line 20:

	The value of a pointer that refers to freed space is indeterminate.

From the definition of undefined behavior, section 1.6, page 3, lines 23-25:

	Undefined behavior -- behavior, upon use of a nonportable or erroneous
	program construct, of erroneous data, or of indeterminately-valued
	objects, for which the Standard imposes no requirements.

Thus, an architecture is free to trap on the above code.  This was a
deliberate choice of the Committee.

Dave Prosser	...not an official X3J11 answer...