Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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?

+5
−0
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.

Related: https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

2 answers

+4
−0

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."

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Indeterminate pointers (1 comment)
+2
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Assumptions; C23 (4 comments)

Sign up to answer this question »