I've never bought this argument. If wrapping signed arithmetic (-fwrapv) were the default, and an overflow occurred, then most programs would still not function

I've never bought this argument. If wrapping signed arithmetic (-fwrapv) were the default, and an overflow occurred, then most programs would still not function as intended. Basically your argument is that programmers should be implementing: https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+Ensure+that+unsigned+integer+operations+do+not+wrap https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+Ensur... instead of: https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensur... Both of these solutions are garbage, and blaming the compiler because your language (C) is too weak to help you out is shrugging off responsibility. In places where overflow is likely to matter from a security perspective (parameters derived from user input for example), what mode is used is irrelevant. It's actually easier for a programmer to check for overflow using a safe compiler intrinsic[0] (or in C++ use a checked[1] or multiprecision[2] integer library) than it to correctly implement their own checks. [0] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... [1] https://www.boost.org/doc/libs/1_74_0/libs/safe_numerics/doc/html/index.html https://www.boost.org/doc/libs/1_74_0/libs/safe_numerics/doc... [2] https://www.boost.org/doc/libs/1_74_0/libs/multiprecision/doc/html/index.html https://www.boost.org/doc/libs/1_74_0/libs/multiprecision/do...