[gavinhoward]

I am one of the "stop exploiting UB" camp. [1]

I agree that some of us are unreasonable, but I do recognize that DWIM is not feasible.

I just want compilers to treat UB the same as unspecified behavior, which cannot be assumed away.

[1]: https://gavinhoward.com/2023/08/the-scourge-of-00ub/

[tialaramex]

You mention that "Note that those surprised programmers are actually Rust compiler authors" but I can't figure out which of the many links is to some "surprised programmers" who are actually rustc authors, and so I don't even know if you're right.

Rust's safe subset doesn't have any UB, but the unsafe Rust can of course cause UB very easily, because the rules in Rust are extremely strict and only the safe Rust gets to have the compiler ensure it doesn't break the rules. So it seems weird for people who work on the compiler guts to be "surprised".

[pcwalton]

I'm a Rust compiler author, and I'm fully in favor of "UB exploitation". In fact, LLVM should be doing more of it. LLVM shouldn't be holding back optimizations in memory-safe languages for edge cases that don't really matter in practice.

[gavinhoward]

https://github.com/rust-lang/rust/issues/28728

[muldvarp]

I don't see any surprised compiler authors in that thread. The reporter immediately suggests the correct underlying reason for the bug and another compiler author even says that they wondered how long it would take for someone to notice this.

Even if you read any surprise into their messages they wouldn't be surprised that C does something completely unreasonable, they would be surprised that LLVM does something unreasonable (by default).

[tialaramex]

Wait, that's not even linked in your post AFAICT. It's also about an LLVM bug and not in fact exploiting UB.

"LLVM shouldn't miscompile programs" is uncontroversial, but claiming that these miscompilations are somehow "Exploiting Undefined Behaviour" is either incompetent or an attempt to sell your position as something it isn't.

[muldvarp]

> I just want compilers to treat UB the same as unspecified behavior, which cannot be assumed away.

Unspecified behavior is defined as the "use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance".

Which (two or more) possibilities should the standard provide for out-of-bounds writes? Note that "do what the hardware does" wouldn't be a good specification because it would either (a) disable all optimizations or (b) be indistinguishable from undefined behavior.