Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

The C standard (and the C++ standard) do not define flags that change the meaning of a program, because they are trying to define a single language; if something is implementation defined, then the implementation gets to say exactly what that means for this implementation, including whether or not the implementation's definition can be changed by compiler flags.

There's four varieties of incompletely standardised behaviour for a standards-compliant program that do not require diagnostics in all cases (I'm ignoring problems that require a diagnostic, since if you ignore warnings from your compiler, that's on you):

1. "ill-formed program". This is a program which simply has no meaning at all in the standard. For example, I am a fish. I am a fish. I am a fish is an ill-formed program (albeit one that requires a diagnostic). Ill-formed programs can always be optimized down to the null statement.
2. "undefined behaviour". This is a case where, due to input data or program constructs, the behaviour of the operation is undefined, and the consequence of that undefinedness is that the entire program has no meaning attributed to it by the standard. A compiler can do anything it likes once you've made use of UB, but in order to do this (e.g. compile down to the null statement), the compiler first has to show that you're using UB; e.g. you've executed a statement with undefined behaviour, such as arithmetic overflow in C99. If you do something that has UB in some cases but not others, the compiler can assume that the UB cases don't happen.
3. "unspecified behaviour". The behaviour of the program upon encountering unspecified behaviour is not set by the standard, but by the implementation. The implementation does not have to document what the behaviour will be, nor remain consistent between versions. Unspecified behaviour can be constrained by the standard to a set of possible options; for example, C++03 says that statics initialized via code are initialized in an unspecified order, but for each initializer, all statics must either be fully-initialized or zero-initialized at the point the initializer runs. This means that code like int a() { return 1; }; int b = a(); int c = b + a(); can set c to either 1 (b was zero-initialized) or 2 (b was fully-initialized), but not to any other value. However, because this is unspecified, the behaviour can change every time you run the resulting executable.
4. "implementation-defined behaviour". The behaviour of the program upon encountering unspecified behaviour is not set by the standard, but by the implementation. The implementation must document what behaviour it chooses; like unspecified behaviour, the allowed options may be set by the standard.

And it's been the case in the past that programs have compiled down to the null statement because they always execute UB; the problem with the SPECint 2006 benchmark in question is that it's conditionally UB in the C standard language, and thus the compiler must produce the right result as long as UB does not happen, but can do anything if UB happens.

Right, but you're a rarity. I see that big visible users of C (Debian, Fedora, Ubuntu, SLES, RHEL, FreeRTOS, ThreadX and more) don't set default flags to define more behaviour in C, while at the committee level John Regehr (part of the CompCert verified compiler project) could not get agreement on the idea that the ~200 UBs in the C standard should all either be defined or require a diagnostic from the compiler. And compiler authors aren't pushing on the "all UB should either be defined or diagnosed" idea, either.

So, for practical purposes, C users don't care enough to insist that their compilers define behaviours that the standard leaves undefined, nor do they care enough to insist that compilers must provide diagnostics when their code could execute UB (and thus is, at best, only conditionally valid). The standard committee doesn't care, either; and compiler authors aren't interested in providing diagnostics for all cases where a program contains UB.

From my point of view, this is a "C culture overall is fine with UB" situation - people have tried to get the C standard to define more behaviours, and the in charge of the C standard said no. People have managed to get compilers to define a limited set of behaviours that the standard leaves undefined, and most C users simply ignore that option - heck, if C users cared, it would be possible to go through the Fedora Change Process, or the Debian General Resolution process to have those flags set on by default for entire distributions, overruling the compiler maintainers. Given the complete lack of interest in either top-down (start at the standards body and work down) or bottom-up (get compiler writers to introduce flags, set them by default and push for everyone to set them by default) fixes to the C language definition, what else should I conclude?

And note that in the comments to this article, we have someone who agrees that too much of C is UB saying that they'll not simply insist that people use the extant compiler flag and rely on the semantics that are created by that - which is basically C culture's problem in a nutshell; we have a solution to part of the problem, but we're going to complain instead of trying to push the world to a "better" place.

How would that work? If you call assembler function then it may do literally anything with any part of the code and data at any point in the future. How can compiler and compiler writers guarantee ANYTHING AT ALL if the requirement is to ensure that code work with adversary which changes everything and anything in your program randomly?

You can not do that if you wouldn't limit parts of the assembler in your program. Heck, on most platforms that assembler part may install “random flipper” which would, after starting it, randomly flip bits in the accessible code and data areas. How can you predict result of 256 * 256 in the presence of such “helper”? How can you predict anything at all?

Sure. But what's the point? If some random guy or gal insists that any UB must be handled by SANE language predictably, even “random bit flipper” in your process, then your only choice is to sigh and start tedious process of reviewing or removing code written by such a person, what other choice is there? Such person clearly doesn't understand how program development work, if s/he wrote anything that actually works, by accident, you may never be sure it wouldn't stop working at random time in the future.

Yes, lots of C/C++ UBs may be redeclared as not UBs. But that would never satisfy O_PONIES lovers which insist of entirely different treatment of UB and as long as they are part of you community… any semblance of safety is impossible.

What's the point of that stupidity? If you want predictability then it's much better to just fully specify the result. If you want portability then UB is better because it makes you code usable on wider range of systems.

What the hardware gives you is pretty much useless: it gives you neither predictability nor portability, why even bother?

Because that the only way to apply as if rule. Optimizations should preserve behavior of the program. But if your program doesn't have a predictable behavior then it's impossible to answer the question of whether optimization would preserve it or not.

Once more: consider the following code:

void foo(int x) {
  int y = x;
}

This piece doesn't include UB, doesn't do anything strange, it only does one simple (if useless) assignment.

But if you remove that assignment you may break some other piece of code!

Cases like these make optimizations of programs that may trigger UB pretty much impossible. Critically: it makes it impossible to even optimize these parts of the code that don't trigger UB.

Why are you so sure? How can you know that that 99% of people don't want these optimizations? On the contrary: when an attempt was made to find out what optimizations people actually want then almost every UB was found to be liked to significant percentage of developer.

You mean something like CompCert C? It's not too much popular. If people actually wanted what you preach then they would have switched to it in droves.

In reality… I think there are more Rust users than CompCert C users.

Without a single language definition you no longer have a community, you have bunch of silos and each one not too big.

Now go and convince the Clang, GCC, Fedora or Debian maintainers that this should be the default state. That's the hard part - getting anyone whose decisions will influence the C standards body to declare that they want less UB, even at the expense of a few % of speed on some benchmarks.