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
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 ca...
Answer
#1: Initial revision
by
Lundin
·
2023-04-03T06:59:18Z (over 1 year ago)
`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.