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...