[MauranKilom]

> But as long as there are limits, the definition of undefined was never valid.

There are always limits. Your CPU is (for the most part) deterministic, and no amount of UB will change that (well, the nuclear missiles launched due to UB might...).

> It seems to me that the problem is that trying to define undefined behavior is an inherent contradiction.

Here is the definition of UB according to the C++ standard:

    "This document imposes no requirements on the behavior of programs that contain undefined behavior."  

http://eel.is/c++draft/intro.abstract

Don't try to define or reason about the consequences of UB, that's pointless. Just don't provoke any undefined behavior and you get to live in the clearly defined world of the standard.

> Setting aside the question of what exactly "undefined behavior" means, why does a language spec have to include it? If there is behavior that cannot be defined, why not just omit it from the standard?

"X is UB" means "compiler writers may freely assume that X is not done". If you omit that then compilers would have to verify that X is not done, and there are requirements in the standard which would require the halting problem to be solved in order to verify them in user code. The standard likes to avoid forcing compilers to solve the halting problem.

[perl4ever]

"This document imposes no requirements on the behavior of programs that contain undefined behavior."

The NY Vehicle and Traffic law imposes no requirements on the behavior of drivers who engage in cannibalism. However, it would be odd to interpret this as meaning that if you commit cannibalism, you are exempt from all rules regarding motor vehicles.

There are clearly two kinds of "undefined" behavior - the kind that is defined as undefined, and the kind that is not. To understand either, you have to understand both.

[MauranKilom]

> The NY Vehicle and Traffic law imposes no requirements on the behavior of drivers who engage in cannibalism.

Are you trying to argue that the standard quote is unclear? That you think it can be read "imposes no additional/special requirements" (because that's the interpretation that your traffic law argument assumes)? Because if you ignore the nonsensical meaning, I would read your traffic law sentence as "imposes no requirements whatsoever".

Regardless of what your stance is regarding possible ambiguity in the way that sentence is worded, both the intent and the practical consequences of that statement are abundantly clear: If your program has UB (per what the C++ standard considers UB), then the C++ standard makes absolutely no guarantees what will happen when you run it.

> There are clearly two kinds of "undefined" behavior - the kind that is defined as undefined, and the kind that is not. To understand either, you have to understand both.

I don't understand what you are trying to say. There is only one kind of undefined behavior. If you follow the rules of the C++ standard you get to live in a nice and predictable world. If you don't, anything can happen and you're on your own.

[perl4ever]

There's more than one kind of undefined behavior, and probably more than one way to categorize it.

The distinction I was making is between "what the...standard considers UB" and what the standard doesn't consider period. For instance, the standard doesn't (I assume) declare anything about the effect of cosmic rays on C++ programs. However, that does not mean that C++ compilers are designed or should be designed not to work unless run on equipment that is completely shielded.

There is a semantic difference that seems important to me, but which continually slips away in these discussions. And it's palpably related, for me, to the issues people have with compiler behavior. It's not totally the standard at issue, I don't think, but the culture that provides its context.

It would be nice if following a language standard meant that you get to live in a nice and predictable world, but isn't this an absurd statement?