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
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...
#6: Post edited
by
alx
·
2023-04-02T16:18:38Z (over 1 year ago)
- ```
- 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:- > 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>
- ```
- 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>
#5: Post edited
by
alx
·
2023-04-02T15:35:54Z (over 1 year ago)
- ```
- 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.
- 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:
- > The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).
- Even though this pointer has been initialized, it is certainly indeterminate.
- Related: <https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values>
- ```
- 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:
- > 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>
#4: Post edited
by
alx
·
2023-04-02T15:34:50Z (over 1 year ago)
- ```
- 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.
- 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?
- Related: <https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values>
- ```
- 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.
- 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:
- > The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).
- Even though this pointer has been initialized, it is certainly indeterminate.
- Related: <https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values>
#3: Post edited
by
alx
·
2023-04-02T15:32:59Z (over 1 year ago)
- ```
- 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.
This is the closest 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?
- Related: <https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values>
- ```
- 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.
- 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?
- Related: <https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values>
#2: Post edited
by
alx
·
2023-04-02T15:29:46Z (over 1 year ago)
- ```
- 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.
- This is the closest 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?
- ```
- 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.
- This is the closest 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?
- Related: <https://stackoverflow.com/questions/75533693/clang-15-miscompiles-code-accessing-indeterminate-values>
#1: Initial revision
by
alx
·
2023-04-02T15:29:06Z (over 1 year ago)
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. This is the closest 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?