Undefined Isn’t Unpredictable | Hacker News Reader

Undefined Isn’t Unpredictable

os2museum.com

47 pointsingve17 comments

The problem with redefining instructions to now give defined results where before they were undefined is that software developers might start relying on that defined behaviour, but CPUs from other manufacturers and emulators might still give undefined behaviour. Of course, Intel might not care about that.

Once something has been declared undefined, there is a barrier to changing it to defined, just as much as changing it in the opposite direction.

Could be worse!

I vaguely recall a recent C or C++ standard declaring something UB that wasn't UB before. Kinda hard to search for though, so the exact case so far eludes me.

In general, most of the times when something "newly" becomes UB, it was already UB in practice. The most obvious case was the C11/C++11 definition of INT_MIN % -1 to be UB (as everyone tends to implement % as part of a combined / and % instruction, and INT_MIN / -1 is clearly UB).

what happened to:

  c=-1;

ambiguously being either:

  c = -1;    // c becomes -1

  c =- 1;    // c decremented by 1

Was never a thing?

It's:

    c -= 1; // c decremented by 1

Notice the order is different.

sorry, it was a longer time ago than I realized:

Compound assignment operators of the form =op (such as =-) were changed to the form op= (that is, -=) to remove the semantic ambiguity created by constructs such as i=-10, which had been interpreted as i =- 10 (decrement i by 10) instead of the possibly intended i = -10 (let i be −10).

https://en.wikipedia.org/wiki/C_(programming_language)#K&R_C

Yeah - it goes back prior to 1978!

The meaning depends on context. In hardware, it is common to depend on 'undefined', but stable and predictable behavior. In case of C standard, there is separate 'undefined' and 'unspecified' (and also 'implementation-defined'). And 'undefined' is allowed to be unpredictable and inconsistent, because it is just invalid usage.

Or, arguably, because of a misreading of the standard.

The situation in C++ is similar. With a particular compiler and with a specific set of compilation flags you can sometimes get predictable behavior even if it's undefined (and sometimes not). But, there are no guarantees and if you change compiler, flags or perhaps even some other part of the code the behavior can change.

Perhaps with out of order CPUs relying on something that is undefined could change based on adjacent instructions also?

In case of a CPU it's safer, because the existing hardware definitely won't change, and you can hope the vendor won't do anything drastic in microcode updates.

But UB in a language with an optimizer is a bigger gamble. Even changes to code outside of your UB-tainted function may trip inlining and hot code heuristics, which may make more or less of the code visible to the optimizer, which may make it take advantage of different "undefined" assumptions.

It's not similar at all. It used to be C operations mapped 1-1 to the hardware, so undefined behavior meant unspecified but well-behaved in the sense that it would not randomly change unrelated registers. Now it means "nasal demons", i.e. the compiler can just ignore any execution path with undefined behavior and eliminate it as dead code.

For more, see https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_20... (clearly distinguishing C* which corresponds to the hardware from "C" which is the subset of C* that excludes all undefined behaviour) and https://arxiv.org/pdf/2201.07845.pdf "How ISO C became unusable for operating systems development".

You’re gonna get the same result each time you compile. But if you change _anything_ the results can be completely different. So, I can agree that it’s not a very useful predictability.

There's one big difference between undefined behavior in C and C++. In C++, undefined behavior is ill-formed when it is constant-evaluated. And for aspects which are tricky to determine undefined behavior for, such as reinterpret_cast or type-punning in a union, they're just disallowed in constexpr code entirely. So in C++, you can't necessarily just say "well this is undefined, but it works correctly within our particular constraints", whereas you always can say that in C. That makes implementation-defined a huge difference from undefined. You can always cast signed integers to unsigned integers or vice versa in constexpr code.

Note that the article is about the meaning of "undefined" in CPU instruction documentation, claiming it's rarely or never unpredictable. Nothing to do with the "nasal demons" of C or C++.

(Though comments at the bottom do point out that some of them are situations like a floating bus, where you really do get unpredictable results.)

> The bottom line is that it is very wrong to understand “undefined” in this context as “random”, and even taking it to mean “unpredictable” is at best misleading.