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 Annex J collects portability issues in the C standard itself, referring to the corresponding sections. In J.2, the following seem to be related: - An object is referred to outside of its lifetime (6.2.4). - The value of a pointer to an object whose lifetime has ended is used (6.2.4). - The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8). - The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.22.3). However, looking at the cited section, I see the word "used" is used in a stricter meaning. For example, the last one refers to 7.22.3, where the undefined behavior is defined as: "[...] if the argument does not match a pointer earlier returned by a memory management function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined." 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. Regards, -- Daiki Ueno
