> Whatever the case, we need to start pushing back against this perspective; it is a scourge on our industry, destroying confidence in our code and our compilers.
> And compiler authors need to back down from their “evil” perspective.
Compiler authors are perfectly happy having no UB (that's why things like -fwrapv exist), but customer's revealed preference is that they want code that is X% faster and Y% smaller and they usually don't understand UB (if they even think about it at all).
Then the question comes up "why not make e.g. -fwrapv the default and have -fallow-ub for people who want to opt-in to the safety tradeoff" and this is because very often benchmarks have rules like "all default options except for -O3 (or equivalent)" and even when they don't people run their own benchmarks all the time; if someone compares the default-no-UB compiler to someone else's compiler with UB on by default, they just see that "oh boringcc generates worse code than superunsafecc, let's just user superunsafecc"
I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "superunsafecc," it's called "gcc" or "clang."
> I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "superunsafecc," it's called "gcc" or "clang."
This might be true, but companies often spend a rather short amount of time selecting a compiler for their projects[1], and they won't switch in the middle of it. As long as "reasonable handling of UB" isn't a checkbox in anyone's product selection matrix, then it's not going to get selected.
The current incentives are for compiler writers to ride the very edge of the standard becuase "X% faster" is something that everybody wants. I don't object to the thrust of your article, I just think you are putting everything on the compiler writers, when what compiler users actually use 90% of the time is The compiler that runs their favorite microbenchmark the fastest. The word "want" is complicated, so I used the term "revealed preference" in my first post, but it's not entirely wrong to say that by taking advantage of UB, compiler-writers are giving compiler users what they want; even if we both agree compiler-users want the wrong thing, and would want something different if they were more informed.
As a side-note, I've explained the ISO aliasing rules to dozens of embedded programmers and they are always insistent that C allows free type punning because "C is just portable assembly." I show them -fno-strict-aliasing (or the equivalent for their compiler) and usually they move on, but about 10% of them want to file a bug against the compiler even after having it explained to them.
> I do not believe this relatively novel treatment of undefined behavior is useful for programmers.
I agree. Does UB allow for compilers to do 'rm -rf /' in case of UB? I think some out-of-touch compiler bureaucrats might argue for it, but in practice nobody wants this
UB shouldn't be an excuse to language lawyer your way out of what the programmer wrote (and TFA lists a lot of egregious examples)
> And compiler authors need to back down from their “evil” perspective.
Compiler authors are perfectly happy having no UB (that's why things like -fwrapv exist), but customer's revealed preference is that they want code that is X% faster and Y% smaller and they usually don't understand UB (if they even think about it at all).
Then the question comes up "why not make e.g. -fwrapv the default and have -fallow-ub for people who want to opt-in to the safety tradeoff" and this is because very often benchmarks have rules like "all default options except for -O3 (or equivalent)" and even when they don't people run their own benchmarks all the time; if someone compares the default-no-UB compiler to someone else's compiler with UB on by default, they just see that "oh boringcc generates worse code than superunsafecc, let's just user superunsafecc"