Conversation

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
7
13
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
Replying to and
> 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
Replying to and
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
Replying to and
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
Replying to and
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
Show replies