If something is UB in the standard, the implementations can define it to be something specific instead. That is standards compliant and not a new dialect, as long as the code does not depend on that outcome. > Because of that code that is correct with that flag, is not correct C++ But that is the point of it. Signed overflow has not correct inputs. The preconditions are wrong. An implementation (and its flags) can choose, what happens under those circumstance. That is similar as if you have a contract violation for the contracts feature. A program error was detected and it can be configured, what happens in that case. The program is not correct in the first place, if it comes to such an error.   There is no imaginable use to have wrap-around instead (except that you get a wrong, but the same behavior between different compilers). But no use for wrap-around specifically. You could as well have a result of 0. But the error is not caught either with wrap-around behavior, whereas with UB the compiler may at least give an error, if it detects it at compile-time.   -----Ursprüngliche Nachricht----- Von:Oliver Hunt via Std-Proposals <std-proposals_at_[hidden]> Except... If signed integer arithmetic overflow is UB, then a compiler can easily add run-time checks such as with gcc and clang's "-fsanitize=signed-integer-overflow" flag.  The developer has a quick, simple and efficient way to check for overflow problems - as long as some ignorant developer has not been using "-fwrapv" to sweep the bugs under the rug to wait for after customer deployment.  No, we’re talking about C++, not a different language - compiler flags that change behavior the spec says UB into defined behavior are making the language no longer C++. Because of that code that is correct with that flag, is not correct C++, specifically because C++ says the impacted code is erroneous.  When discussing the properties of a language feature or operation, you need to confine the discussion to the language, not the behavior of non-standard dialects. When people are discussing the safety profile of C++ it is not acceptable to say “well that problem that you raised is solved if you use this compiler flags to change the language”. That is not a selling point, that is another example of “even the compiler writers know that this part of the specification is bad, but they still defined it that way”.  If the language adds a new feature, and the compiler authors from day 1 feel the need to add modes to change the behavior that language feature has been defined incorrectly.