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.
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
Show replies