3 ms·

Not true, as the post explains.

• pclmulqdq 3y ago
  C++20 made the switch. See P1236. It appears C23 has followed suit.
  • e4m2 3y ago
    It made the switch, sure, but overflow remains undefined.
  • rsc 3y ago
    If P1236 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p12...) is really what it says ("alternative wording") then I don't believe that's true. Certainly P0907R3 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r3.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...) is clear: > Status-quo If a signed operation would naturally produce a value that is not within the range of the result type, the behavior is undefined. The author had hoped to make this well-defined as wrapping (the operations produce the same value bits as for the corresponding unsigned type), but WG21 had strong resistance against this. My understanding is that the 2s complement change in C++20 ended up defining bitwise operations but not arithmetic.
  • uecker 3y ago
    Two's complement does not mean signed overflow became defined. So the check is still wrong. And no, I do not think making it defined would lead to more correct programs. You then simply have really difficult wrap-around bugs instead of signed overflow which you can be found more easily with UB sanitizer or turn into traps at run-time.