Falsehoods programmers believe about undefined behavior

Post by marcosdumay » Mon, Nov 28, 2022, 1:25 PM UTC

leni536 wrote: post #22

13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there. 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there. 15. If the line with UB is unreachable code, then the program won't crash because of the UB. 16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point. This…

Post by marcosdumay » Mon, Nov 28, 2022, 1:29 PM UTC

torstenvl wrote: post #40

gpderetta wrote: post #24

Earlier quoted context omitted.

> there are better and worse things compilers can do in the presence of UB, and the big one is warning you about it when it possibly can. GCC should add -Wundefined-behaviour flag that will unconditionally print "warning: this program might or not have UB" as the first diagnostic.

It should also warn if there are infinite loops, so the dev can know whether it will ever halt.

Post by tsimionescu » Mon, Nov 28, 2022, 1:37 PM UTC

haberman wrote: post #63

tsimionescu wrote: post #51

Earlier quoted context omitted.

You have to understand that in the modern understanding of UB as applied by compiler writers, the compiler has every right to assume the program never triggers UB. This means that lines which would be UB if a variable had certain values can be used as proof that the variable doesn't have those values, thereby eliminating checks. For example, if a program looks like this: void foo(int* const p) { if (p!=NULL) { bar(p)…

I don't think this proves the point, because foo() will not invoke UB unless it is called with a NULL argument. It is true that when foo() is called with a NULL argument, the UB will be realized before bar() has had a chance to run (EDIT: this doesn't actually appear to be true for the given code sample, neither Clang nor GCC elide this NULL check: https://godbolt.org/z/v9v74c3jd , which makes sense as bar() could ca…

Post by leni536 » Mon, Nov 28, 2022, 1:40 PM UTC

cvchjfjb wrote: post #67

leni536 wrote: post #42

Earlier quoted context omitted.

UB is typically a property of the execution of a program. A program may bump into UB for one set of inputs, but not for an other set.

That is a misconception. "If any step in a program’s execution has undefined behavior, then the entire execution is without meaning. This is important: it’s not that evaluating (1<<32) has an unpredictable result, but rather that the entire execution of a program that evaluates this expression is meaningless. Also, it’s not that the execution is meaningful up to the point where undefined behavior happens: the bad eff…

Post by anonymoushn » Mon, Nov 28, 2022, 1:48 PM UTC

cvchjfjb wrote: post #34

suprjami wrote: post #26

Earlier quoted context omitted.

No it doesn't. Modern processors do out-of-order execution, so your program might be doing UB before you expect.

No, no, no. UB is a global property of your program. "All bets are off" even at compile time. "Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended." https://blog.regehr.org/archives/213

  int main(int argc, char **argv) {
    int a = atoi(argv[1]);
    int b = atoi(argv[2]);
    return a + b;
  }