Michael Pyne <mp...@kde.org> writes: >> Could you point me to the actual sentence which you think is the case? >> >> - The value of a pointer to an object whose lifetime has ended is used >> (6.2.4). > > This sentence or, alternately, > >> - The value of a pointer that refers to space deallocated by a call to >> the free or realloc function is used (7.22.3). > > The section is really 7.20.3 (at least in the standard I have available) but > either way this text is talking about object lifetime, not passing a pointer > back to free (7.20.3.2) or realloc (7.20.3.4).
I'm reading the N1570 draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf which might be different from the final standard, or earlier versions. > This is important because 6.2.4 specifies that the value of a pointer is only > valid as long as the lifetime of the pointed-to object. Can you quote the sentence please? Also note that 6.2.4 leaves the description about allocated storage in 7.22.3: "There are four storage durations: static, thread, automatic, and allocated. Allocated storage is described in 7.22.3." So, I think all the discussions regarding allocated memory are irrelevant here. > 6.2.4 further says that "The value of a pointer becomes indeterminate > when the object it points to reaches the end of its lifetime." > (i.e. after free() is called). It is unbelievable to me that free() makes a pointer indeterminate, in addition to the pointed memory. Why do you think so, do you have any reference? Unlike 'delete' in C++, free() is implemented as a library function, with the signature of: void free(void *ptr); See described in 7.22.3.3. Which means, without compiler support, the implementation is not able to modify PTR. GCC even provides 'cleanup' attribute which brings the automatic behavior to allocated storage: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes where the cleanup_function takes a pointer to the pointer variable (i.e. TYPE **ptr, not TYPE *ptr) to properly invalidate the pointer variable. Regards, -- Daiki Ueno
