This is interesting. Humans interpret standards and compilers interpret code, too :) We have the benefits of a standard, portability and multiple compilers. Bu

This is interesting. Humans interpret standards and compilers interpret code, too :) We have the benefits of a standard, portability and multiple compilers. But it also comes with duties. BTW. The C++ people seem to tackle some of the issues around widespread 'undefined behavior' and defined a lot of behavior: 1) If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined. i = ++i + 2; // undefined behavior until C++11 i = i++ + 2; // undefined behavior until C++17 f(i = -2, i = -2); // undefined behavior until C++17 f(++i, ++i); // undefined behavior until C++17, unspecified after C++17 i = ++i + i++; // undefined behavior 2) If a side effect on a scalar object is unsequenced relative to a value computation using the value of the same scalar object, the behavior is undefined. cout << i << i++; // undefined behavior until C++17 a[i] = i++; // undefined behavior until C++17 n = ++i + i; // undefined behavior Source: https://en.cppreference.com/w/cpp/language/eval_order https://en.cppreference.com/w/cpp/language/eval_order They replaced the entires "Sequence Point Rules" by "Sequenced-before rules". Compiler implementers cannot choose what to do (implementation defined) or neglect the issue (undefined behavior) - the must act well defined now in many situations.