Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
I see it such that it is undefined behavior (I refer to N1570 as the OP https://port70.net/~nsz/c/c11/n1570.html): After free(p), the lifetime of the object pointed to has ended (7.22.3p1: "The li...
Answer
#1: Initial revision
by
Dirk Herrmann
·
2023-04-13T19:14:30Z (about 1 year ago)
I see it such that it is undefined behavior (I refer to N1570 as the OP https://port70.net/~nsz/c/c11/n1570.html): After `free(p)`, the lifetime of the object pointed to has ended (7.22.3p1: "The lifetime of an allocated object extends from the allocation until the deallocation.") Consequently, the value of `p` becomes indeterminate (6.2.4p2: "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.") Indeterminate means, it could be a trap representation (3.19.2: "indeterminate value[:] either an unspecified value or a trap representation") Certainly, the `free(p)` does not as such change the value of `p`, but I understand this phrase such that it gives the compiler some freedom for optimization. For example, the stack bytes used to hold `p` might be re-used for temporary calculations etc. Such values do not necessarily have to be pointer values, and thus they may have the effect that the value of `p` is changed to a trap representation. Accessing `p` after `free(p)` is therefore undefined behavior: 6.2.6.1 p5: "If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined."