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.
Comments on Can freed pointers undergo lvalue conversion?
Parent
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.
Post
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