In my experience, this is the right thing to do for most applications. Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, instead of just sticking to the input, there will be problems. In particular, you may help some users in some cases, but you'll prevent other users to get what they have the right to have.

> ... seems far less productive ...

And maybe it is, but it's not a compiler's business. Use automatic tools, write your own tools, decide coding convention, impose code reviews, but please let the compiler do what it is supposed to do and how it has learned to do in decades of evolution.

That's one approach to fixing errors, but there's another: tell the programmer that there's an error, and let them decide the best way to fix it. As you say, unsupervised "DWIM" is problematic, and so is a computer program that trusts its inputs absolutely.

> And maybe it is, but it's not a compiler's business.

What exactly isn't a compiler's business? Helping the programmer write a program that solves their problem? I would say that that is 100% of the compiler's job. It might be that part of the problem is "absolute performance", but that is almost always a secondary concern to correctness... computing the wrong answer (or pwning the user's data) is suboptimal, no matter how fast it happens. C defaults to exploiting everything for performance, rather than defaulting to correctness while also providing opt-in ("dangerous") tools for performance that one can use when necessary.

Yes, every time a C program relies on undefined behavior, it's a bug. And as djb observed, virtually all non-trivial C programs contain these bugs. This is the core of my argument.

Yes, we could rely on C programmers never making mistakes. But it would be better to design languages with no undefined behavior.

I do get a facial tick when people say "all significant C programs use (or contain) UB." It's never been necessary and it's always been shameful.

I think the emphasis on the original comment should be on the silent part. Nobody is arguing that these aren't bugs in the code; the problem is that you get no help from the compiler or runtime to find them and the damage is more severe than it would be if it simply crashed.

I think I see your point, but you are wrong when you write "simply". Crashing in case of UB is not simple! Actually, ensuring any type of behavior in case of UB is not simple! It requires huge lots of runtime checks, thus you obtain a ridden executable as output. If you want your program to be cuddled in a safe baby box (which is the right thing to want in several cases), then go for an interpreted language, but please let "gcc -O3 -march=..." be what it is: a masterwork coated with magic.

There are exceptions to every rule, of course, but we need to re-evaluate our priorities as times change.