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.
Can freed pointers undergo lvalue conversion?
char *p, *q;
p = malloc(1);
free(p);
q = p; // lvalue conversion
Is the last lvalue conversion (= p;) Undefined Behavior or not?
We didn't take the address of the local p.
C11::6.3.2.1/1 contains the following sentence regarding lvalue conversions:
If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.
https://port70.net/~nsz/c/c11/n1570.html#6.3.2.1p2
This is the closest normative sentence that seems to apply. Since pointers lose their value after the lifetime of their pointee expires, one could think of them as uninitialized variables (for most purposes they act like them). But reading the standard pedantically, I can't agree with this statement of mine, because an assignment to p has certainly been made previously (p = malloc(1);).
Would instead an implicit Undefined Behavior apply due to the standard not clearly defining it?
Or is this defined behavior?
The informative Annex J has something more generic which would make this UB, but it is non-normative (and doesn't even point to this specific section of the standard):
The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).
https://port70.net/~nsz/c/c11/n1570.html#J.2
Even though this pointer has been initialized, it is certainly indeterminate.
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| alx | (no comment) | Apr 20, 2023 at 21:52 |
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."
p is assigned a value and then it becomes indeterminate when the pointed at object has reached the end of its lifetime (C17 6.2.4).
Pointers may have trap representations (C17 6.2.6.1/5) and in case the indeterminate value matches a trap representation, the assignment q = p; invokes undefined behavior. However, since p used to hold a valid value and since free() can't change p, then p cannot hold a trap representation in this specific case.
In other situations where p is indeterminate just because it wasn't initialized or because it was somehow assigned a garbage value, then it might contain a trap representation.
However, since p and q are now indeterminate, nothing can be assumed about them - their values are unspecified. They cannot even assumed to be equal and in case they are passed to standard library functions, the code invokes undefined behavior.
As for Annex J, it is often misleading and full of strange references towards chapters that supposedly should back up the wording in the Annex, while in fact it doesn't. "The value of an object with automatic storage duration is used while it is indeterminate" is not mentioned to be UB in any normative text in 6.2.4, 6.7.9 nor 6.8. Annex J.2 has several such defects.
0 comment threads