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

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."

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.

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()?

Replying to

and

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.

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.

Replying to

and

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.

Replying to

and

twitter.com/kardonice/stat You could argue that while(1); being transformed into nothingness is well-defined. But it’s shocking for a lot of programmers. And I would be curious if any compiler actually does that in practice.

Quote Tweet