On Tue, May 10, 2016 11:22:58 Daiki Ueno wrote: > Michael Pyne <mp...@kde.org> writes: > > On Mon, May 9, 2016 08:51:56 Daiki Ueno wrote: > >> Follow-up Comment #3, bug #47847 (project gettext): > >> > >> Thanks for the comment, Bruno. > >> > >> The reasoning sounds convincing, but I'm a bit confused that there is no > >> such path in the original code. ISO C 6.2.4 also says: "The result of > >> attempting to indirectly access an object with automatic storage duration > >> from a thread other than the one with which the object is associated is > >> implementation-defined", but I neither see a possibility of this. > >> > >> So far, the more I think of this, the more it seems like a false positive > >> (and if so, perhaps we could add an annotation instead to suppress the > >> warning). > > > > It is absolutely not a false positive. It is warning because the pointer > > is > > referred to after it has been free()'d. This is a class of behavior which > > is explicitly described as undefined behavior in the C standard (Annex > > J.2 lists the conditions if you have the reference handy, as does the > > CERT link I provided in the bug link). > > 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). 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. 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). *This* is important since use of an "indeterminate" value is what is undefined here. Not "use in free()" or "use in realloc()" but *any use* at all. For example if you keep reading in 6.2.4 it says that "The initial value of the object [of automatic storage duration] is indeterminate". In other words the same verbiage that makes using an uninitialized value on the stack undefined behavior (at least, I hope we all agree this is UB...), is also used to reference use (any use) of a free()'d pointer. > So, if I read it correctly, the behavior is undefined only if the > pointer value is used as an argument of free or realloc, not in a > general expression. That much is true for the C standard library memory management functions, but not for pointers in general (per 6.2.4). The value of a pointer cannot be used after it has been deallocated, either by free() or realloc(). Regards, - Michael Pyne
