Can we PLEASE stop saying shit like "doing whatever is UB and makes the compiler free to replace your code with `rm -rf`"
until somebody puts system() calls in the LLVM replacement engine, this is just lazy trite garbage
Conversation
Replying to
You're catching a lot of twitter flak for this, but you're right. There is ~zero chance that UB will lead to wiping your hard drive unless exploited by an attacker.
The correct phrasing is "You should care about UB because it raises the chance that an attacker can exploit it."
1
1
> unless exploited by an attacker
This is an enormous caveat, and it's also definitely not the only reason that you should care about it. If you want to write software that's reliable and safe, undefined behavior is a huge problem even without considering security.
1
9
Depends how you define “problem”.
The issue is that a vocal minority of programmers see UB code as a problem. while(1); is UB before C11, but it was never a problem, except to compiler authors.
After all, how would you make a thread loop forever without calling abort()?
2
In fact, it might be impossible to formally verify both the compiler toolchain and all emitted code. Godel has a few things to say on the subject.
1
1
You're misinformed about what was changed and the impact of the change. I suggest referring to the C11 standard. It's a controversial change but isn't tied to what the standard says is undefined behavior. There's a big difference between permitted implementation choices and UB.
1
Refer to the parallel thread in this chain. There is a long discussion about it, and the consensus seems to be that infinite loops either were or are undefined behavior in some cases.
2
A Twitter thread isn't the C standard. Quote what makes `while (1)` undefined in C99.
> An iteration statement causes a statement called the loop body to be executed repeatedly until the controlling expression compares equal to 0.
I would suggest people don't make stuff up.
1
Somehow I knew this reply was coming...
No, a twitter thread isn’t the C standard. But there are a lot of smart people in this thread, including someone who works on the Swift compiler. Arguments from authority are less valid, but in those cases the burden of proof is elsewhere.
1
The point of allowing while(1) to be turned into nothingness is that a lot of transformations end up doing the equivalent of while(1){} because the loop body was evaporated along with the conditional.
I think. I’m still not entirely concrete on the subject.
1
C89 and C99 don't permit this. C11 permits assuming that a subset of infinite loops terminate, but it never applies to any loop like `while (1) { ... }` because that's a constant expression that's true. It also doesn't apply if the loop has any side effects. It's also a change.