Undefined behavior in C is a reading error

> license for the kinds of dramatic and unintuitive transformations we’ve seen from the compilers, and any indication that undefined behavior should be a vehicle for permitting optimizations.

Does anyone have an example of a time where Clang or GCC actually did something bad upon witnessing undefined behavior, rather than simply doing nothing, as the standard proposes? I ask because every time I've seen people get mad about UB it's always because they envisioned that the compiler would do something, but instead the compiler did nothing.

I'm not convinced. The argument seems to hinge to a very large extent on the sentence:

> Permissible undefined behavior ranges from A, to B, to C.

The observation that "Permissible" has a specific meaning is important and interesting. But what about "ranges from ... to ..."? The author reads this as "Permissible undefined behavior is either A or B or C.", but that seems like a stretch to me. (Unless ISO defines "ranges" to mean just this.)

Also, in the above, A = "ignoring the situation completely with unpredictable results". Both "ignoring" and "unpredictable" do a lot of heavy lifting here. In the signed integer overflow case discussed in the linked GCC bug report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475), one could very well argue that "ignoring" a case where signed arithmetic overflows is exactly GCC is doing. It "ignores" the possibility that a + 100 might overflow, hence obviously a + 100 > a is true, leading to results that the reporter considers "unpredictable". Somehow the author seems to think that this is not what the wording intended, but they also fail to explain what they think should happen here.

Sounds to me like the wording has always been very vague.

Also:

> Returning a pointer to indeterminate value data, surely a “use”, is not undefined behavior because the standard mandates that malloc will do that.

Yes, malloc will do that, but using a pointer to indeterminate data is not the same as using the indeterminate data itself. The author is doing themselves a disservice by misreading this.

I'm afraid the author themselves is misreading the definition of undefined behavior. Undefined behavior is not "behavior upon use of a nonportable or erroneous program construct". That rephrasing completely changed the meaning. Undefined behavior is, as the C standard states, "behavior [, ...,] for which the Standard imposes no requirements". The whole ", upon use of...," part is just exemplifying situations in which undefined behavior can occur. The standard will sometimes say that a certain construct results in undefined behavior but more importantly any construct for which the standard does not specify a certain behavior has (what else?) undefined behavior.

What do you think UB is if not something where the behaviour is not defined?

I think the reasoning here is flowing backwards.

The writer wants to believe that C is a well-designed language suitable for writing large programs (because programmers understandably use it that way; there's not really an alternative to C), and so people reading the spec and finding a minefield _must_ be reading the spec wrong. So many important programs are written in C, and so many of them, with a very strict reading of the C standard, can hit cases where their behavior is "undefined". This _is_ scary, if the C-language-lawyers are right!

The C language was originally largely descriptive, rather than prescriptive. Early "C" compilers disagreed on what to do in strange cases (e.g., one might wrap integer overflow, one might saturate, one might have wider ints). Even when using the less-chaotic "implementation defined behavior", behavior can still diverge wildly: `x == x + 1` is definitely `false` under some of those interpretations and maybe `true` in some of those interpretations.

However, the C spec clearly says that the compiler may "ignore the situation" that "the result is ... not in the range of representable values for its type"; it is "permissible" that `x == x + 1` is replaced with `false` despite the "actual" possibility that adding 1 to x produces the same value, if `+` was compiled to be a saturating add.

This has significant practical consequences, even without the "poisoning" result commonly understood of undefined behavior. Since the value is known statically to be `false`, that might be inlined into a call into a function. That function may _dynamically_ re-check `x == x + 1` and find that it is `true`; obviously that function doesn't have a `if (true && false) {` case, so it results in the function misbehaving arbitrarily (maybe it causes a buffer overrun to the argument of a syscall!).

'Intuition' does not make a programming-language semantics. You need to write down all the rules. If you want to have a language without undefined behavior, you need to write down the rules for what must happen, keeping in mind that many examples of undefined behavior, like dereferencing out-of-bounds pointers, _cannot_ be detected dynamically in C without massive performance costs. To detect if a pointer is out-of-bounds, you need to always pair it with information about its provenance; you need to track whether or not the object has been freed, or the stack-frame it came from has expired. Is replacing all pointers with fat-pointers indicating their provenance and doing multiple comparisons before every dereference the "right" way to compile C?