Wrong; one example: your CPU's instruction set has well defined behavior for signed integer overflow. C doesn't.

That does not contradict what was said. C says "undefined" so that compilers are free to simply let each CPU do whatever is easiest for that CPU. On any particular CPU with a particular compiler you get consistent behavior. But when you switch CPUs, watch out.

Thus YOUR SPECIFIC CPU's instruction set may be well-defined. But if you say "your CPU" to a group of people with different CPUs, there may be no simple statement that is well-defined and generalizable across all of them.

> C says "undefined" so that compilers are free to simply let each CPU do whatever is easiest for that CPU. On any particular CPU with a particular compiler you get consistent behavior. But when you switch CPUs, watch out.

That was how it worked in the 1990s. Nowadays, a C programmer needs to figure out which undefined behaviors are justifiable and which should be avoided at all costs because they will be used by the compiler to justify optimizations. And Signed arithmetic overflow used to be in the first category, now it is in the second one. So is the use of uninitialized variables.

Not to appeal to authority, but I worry about these things for a living:

http://blog.frama-c.com/index.php?post/2013/07/11/Arithmetic...

http://blog.frama-c.com/index.php?post/2013/05/20/Attack-by-...

If you cannot be bothered to read that much, then please simply compile int f(int x) { return x + 1 > x; } at different optimization levels with the compiler you already have, and observe the values for f(INT_MAX) in each case.

Thank you for the update to my knowledge. I'm not a C programmer, and have been relying on older explanations of why C does what it does.

You're thinking of "implementation defined" which are required to have well-defined behaviors. "undefined" is far more pernicious.