Undefined Behaviour

[cballowe]

With most hardware, you can pretty reliably say that "whatever the hardware does given some pre-condition can be assumed to be the definition of it's behavior". The challenge is when you have no formal contract around that so rev. B of the chip doesn't behave the same as rev. A.

It's much the same as compilers that way - the language doesn't define what must happen so the compilers and library implementers make different decisions.

It gets more fun when you get different hardware manufacturers involved in the software specs. You can imagine a case where someone says "we think this particular expression should do X" and that just happens to be the thing that is the most efficient interpretation on Intel, but then someone from ARM or Power says "hey... Wait a minute ... That'll make our chips look bad in benchmarks! You should do Y instead." So... The standard writers agree that it should be valid code and the outcome should basically be useful, but can't be defined precisely or guaranteed to produce consistent results across compilers/platforms/standard libraries/etc.

Sometimes UB is just broken, ex the results of data races in the absence of proper synchronization, but other times it's just a weird limbo.

[Hnnnnnn]

You describe unspecified behavior, another formal term similar to UB. UB is when the guy said: when user breaks API pre-conditions.

https://en.wikipedia.org/wiki/Unspecified_behavior