5 ms·

No, it isn't. The line with UB has to be reached in the execution for the execution to be undefined.

deleted 4y ago
[deleted]
throwaway294566 4y ago
Yes, but there is more to it: The compiler may assume that UB will never happen intentionally and optimize out the branch containing UB.
tsimionescu 4y ago
The compiler isn't required to know if code is unreachable. For example, `if (fermats_last_theorem_is_wrong()) {*p == 1} ` will imply to a modern compiler that p is not NULL in the scope where it is defined, even if we now know that this code will never be reached (assuming that function is correctly written). Or, here is a better example: for(int i=0; i > n;) { } *p=1; Here the compiler will assume that the loop terminates, since non-terminating loops without side-effects are UB in C++. Then, since the loop terminates, p will be dereferenced, so it can be assumed that p is never NULL, so any NULL checks for p in this context can be ellided. This remains valid even if you call this function with an n such that *p=1 is unreachable.
- caf 4y ago
  If a some translation unit defines int fermats_last_theorem_is_wrong(void) { return 0; } then a well-defined program can execute that sequence even with p equal to NULL.
- haberman 4y ago
  The compiler is required to successfully translate a program that contains unreachable UB, and such a program is conforming if undefined behavior is never reached. This is explicitly spelled out in https://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_109.html https://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_109.html > Furthermore, if every possible execution of a given program would result in undefined behavior, the given program is not strictly conforming. A conforming implementation must not fail to translate a strictly conforming program simply because some possible execution of that program would result in undefined behavior. Because foo might never be called, the example given must be successfully translated by a conforming implementation.
  - account42 4y ago
    Sad to see this downvoted here. To hammer it in, the consider the following: if(p) *p = 0; *p is undefined if p is NULL. But as long as that statement is never reached when p is NULL that is not a problem. That is trivially true in this case, but the same applies even for more complex relations between the conditional and the undefinedness of the statement. Or put another way, in int * p = 0; if(fermats_last_theorem_is_wrong()) { p = malloc(sizeof(int)); *p = 0; } if(p) { puts("fermats last theorem is wrong\n"); } if(fermats_last_theorem_is_wrong()) { *p == 1; } if(p) { puts("fermats last theorem is wrong\n"); } the compiler is not allowed to remove the if(p) checks and unconditionally print that fermats last theorem is wrong unless it can prove that fermats_last_theorem_is_wrong() is true. In fact, something having undefined behavior and the compiler being allowed to assume that it is unreachable are effectively the same thing. Which is why the spec for std::unreachable() and the compiler-specific intrinsics that preceded it is that it invokes undefined behavior and not more complex wording.
    - tsimionescu 4y ago
      Yes, my example with Fermat's last theorem was completely wrong, not sure why it seemed plausible to me when I wrote it, it's obviously just a guard, and it obviously is not UB to have a pointer write behind an If...
- mnw21cam 4y ago
  Presumably (and really don't take my word for this - I'm a Java bod) the p dereference needs to come before the p NULL check for the p NULL check to be ignored. (Otherwise, how can a NULL check protect a dereference.) And therefore, the NULL check would be unreachable as well, and therefore never executed and not relevant. Please correct my misunderstanding...
  - adgjlsfhk1 4y ago
    Nope, the C spec is just really bad. The NULL check is allowed to be removed.
    - mnw21cam 4y ago
      So the pseudocode: if (p is not NULL) { dereference p } is UB? That's crazy, but not actually unbelievable.
      - dllthomas 4y ago
        I am not certain of the language lawyer side of it, but no reasonable (or even moderately unreasonable) compiler would omit that check because of the guarded behavior; way too much code would break, probably including that compiler's standard library.
      - UncleMeat 4y ago
        The poster is just completely wrong. A compiler is required to emit the branch in this case.
  - tsimionescu 4y ago
    There's no misunderstanding on your part, just some muddled thinking on my part for the first example.
- account42 4y ago
  > For example, `if (fermats_last_theorem_is_wrong()) {*p == 1} ` will imply to a modern compiler that p is not NULL in the scope where it is defined, even if we now know that this code will never be reached (assuming that function is correctly written). No it won't. Otherwise all precondition checks would be meaningless. The compiler can only assume that it isn't null when fermats_last_theorem_is_wrong() is true. If the compiler cannot reason about fermats_last_theorem_is_wrong() then it can't just ignore it. > for(int i=0; i > n;) { } *p=1; > Here the compiler will assume that the loop terminates, since non-terminating loops without side-effects are UB in C++. Infinite loops are UB precisely because otherwise the compiler would NOT be able to reason about this. So yes, here the comiler can assume that p is a valid pointer - but only because it can also assume that *p=1 is NOT dead. This falls entirely under the umbrella of behavior not being defined at all after you execute undefined behavior (the infinite loop). > This remains valid even if you call this function with an n such that *p=1 is unreachable. Only because the loop itself is undefined behavior in that case.
  - AstralStorm 4y ago
    That is not an infinite loop, it has an exit condition on i > n. An infinite loop is not UB. It is well defined. Just the definition of a terminating loop is a bit funny. > An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression, may be assumed by the implementation to terminate. Plus: > An omitted controlling expression is replaced by a nonzero constant, which is a constant expression. The compiler may only use as-if rule here if it can deduce the value is constant or limited. It can (but does not have to) assume the loop will end due to the conditional and lack of the other features. Which is still defined behavior. (since C11 at least, probably earlier)
    - haberman 4y ago
      > An infinite loop is not UB. It is well defined. From C11: > An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate.157) > 157)This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven. This makes infinite loops UB unless they fall under one of these exceptions (constant controlling expression, performs I/O, accesses volatile objects or atomics).
deleted 4y ago
[deleted]

deleted 4y ago

[deleted]

Yes, but there is more to it: The compiler may assume that UB will never happen intentionally and optimize out the branch containing UB.

tsimionescu 4y ago

The compiler isn't required to know if code is unreachable. For example, `if (fermats_last_theorem_is_wrong()) {*p == 1} ` will imply to a modern compiler that p is not NULL in the scope where it is defined, even if we now know that this code will never be reached (assuming that function is correctly written). Or, here is a better example: for(int i=0; i > n;) { } *p=1; Here the compiler will assume that the loop terminates, since non-terminating loops without side-effects are UB in C++. Then, since the loop terminates, p will be dereferenced, so it can be assumed that p is never NULL, so any NULL checks for p in this context can be ellided. This remains valid even if you call this function with an n such that *p=1 is unreachable.

caf 4y ago
If a some translation unit defines int fermats_last_theorem_is_wrong(void) { return 0; } then a well-defined program can execute that sequence even with p equal to NULL.
haberman 4y ago
The compiler is required to successfully translate a program that contains unreachable UB, and such a program is conforming if undefined behavior is never reached. This is explicitly spelled out in https://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_109.html https://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_109.html > Furthermore, if every possible execution of a given program would result in undefined behavior, the given program is not strictly conforming. A conforming implementation must not fail to translate a strictly conforming program simply because some possible execution of that program would result in undefined behavior. Because foo might never be called, the example given must be successfully translated by a conforming implementation.
- account42 4y ago
  Sad to see this downvoted here. To hammer it in, the consider the following: if(p) *p = 0; *p is undefined if p is NULL. But as long as that statement is never reached when p is NULL that is not a problem. That is trivially true in this case, but the same applies even for more complex relations between the conditional and the undefinedness of the statement. Or put another way, in int * p = 0; if(fermats_last_theorem_is_wrong()) { p = malloc(sizeof(int)); *p = 0; } if(p) { puts("fermats last theorem is wrong\n"); } if(fermats_last_theorem_is_wrong()) { *p == 1; } if(p) { puts("fermats last theorem is wrong\n"); } the compiler is not allowed to remove the if(p) checks and unconditionally print that fermats last theorem is wrong unless it can prove that fermats_last_theorem_is_wrong() is true. In fact, something having undefined behavior and the compiler being allowed to assume that it is unreachable are effectively the same thing. Which is why the spec for std::unreachable() and the compiler-specific intrinsics that preceded it is that it invokes undefined behavior and not more complex wording.
  - tsimionescu 4y ago
    Yes, my example with Fermat's last theorem was completely wrong, not sure why it seemed plausible to me when I wrote it, it's obviously just a guard, and it obviously is not UB to have a pointer write behind an If...
mnw21cam 4y ago
Presumably (and really don't take my word for this - I'm a Java bod) the p dereference needs to come before the p NULL check for the p NULL check to be ignored. (Otherwise, how can a NULL check protect a dereference.) And therefore, the NULL check would be unreachable as well, and therefore never executed and not relevant. Please correct my misunderstanding...
- adgjlsfhk1 4y ago
  Nope, the C spec is just really bad. The NULL check is allowed to be removed.
  - mnw21cam 4y ago
    So the pseudocode: if (p is not NULL) { dereference p } is UB? That's crazy, but not actually unbelievable.
    - dllthomas 4y ago
      I am not certain of the language lawyer side of it, but no reasonable (or even moderately unreasonable) compiler would omit that check because of the guarded behavior; way too much code would break, probably including that compiler's standard library.
    - UncleMeat 4y ago
      The poster is just completely wrong. A compiler is required to emit the branch in this case.
- tsimionescu 4y ago
  There's no misunderstanding on your part, just some muddled thinking on my part for the first example.
account42 4y ago
> For example, `if (fermats_last_theorem_is_wrong()) {*p == 1} ` will imply to a modern compiler that p is not NULL in the scope where it is defined, even if we now know that this code will never be reached (assuming that function is correctly written). No it won't. Otherwise all precondition checks would be meaningless. The compiler can only assume that it isn't null when fermats_last_theorem_is_wrong() is true. If the compiler cannot reason about fermats_last_theorem_is_wrong() then it can't just ignore it. > for(int i=0; i > n;) { } *p=1; > Here the compiler will assume that the loop terminates, since non-terminating loops without side-effects are UB in C++. Infinite loops are UB precisely because otherwise the compiler would NOT be able to reason about this. So yes, here the comiler can assume that p is a valid pointer - but only because it can also assume that *p=1 is NOT dead. This falls entirely under the umbrella of behavior not being defined at all after you execute undefined behavior (the infinite loop). > This remains valid even if you call this function with an n such that *p=1 is unreachable. Only because the loop itself is undefined behavior in that case.
- AstralStorm 4y ago
  That is not an infinite loop, it has an exit condition on i > n. An infinite loop is not UB. It is well defined. Just the definition of a terminating loop is a bit funny. > An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression, may be assumed by the implementation to terminate. Plus: > An omitted controlling expression is replaced by a nonzero constant, which is a constant expression. The compiler may only use as-if rule here if it can deduce the value is constant or limited. It can (but does not have to) assume the loop will end due to the conditional and lack of the other features. Which is still defined behavior. (since C11 at least, probably earlier)
  - haberman 4y ago
    > An infinite loop is not UB. It is well defined. From C11: > An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate.157) > 157)This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven. This makes infinite loops UB unless they fall under one of these exceptions (constant controlling expression, performs I/O, accesses volatile objects or atomics).

deleted 4y ago

[deleted]