Signed Integer Overflow UB
This cluster centers on signed integer overflow being undefined behavior (UB) in C/C++, allowing compilers to optimize away overflow checks and assume no overflow occurs, with debates on security risks, alternatives like wrapping or trapping, and comparisons to Rust's debug panics and release wrapping.
Activity Over Time
Top Contributors
Keywords
Sample Comments
In some languages overflow is asserted as a can't happen and so the optimizer will remove your checks
Signed integer overflow is undefined in C, so optimizers can do really weird things to code that has overflows.
Signed overflow is UB in C/C++ and several compilers will skip explicit overflow checks as a result. See: https://godbolt.org/z/WehcWj3G5
Integer overflow is actually undefined behaviour thus the compiler is free to assume it doesn't happen.
That's correct! C doesn't require checking for overflows, but it also doesn't forbid implementations from doing so. both are features.
By default yes, but you can enable overflow checking in release mode (itβs a conf / compiler flag), and it has standard functions for checked, wrapping, and saturating ops.
When I hear about making overflow safe by making it wrap my main question is how much code is actually ready for overflow? I've seen many vulnerabilities where a bounds check was bypassed because a computation overflowed. It seems that the only really safe behaviour here is crashing. If you aren't going to pay the cost of these checks may as well call it undefined behaviour and allow optimizations. (of course also including wrapping integer types in your language for when you do want t
While not standardized, there are compiler builtins for operations which care about overflow. They will not be optimized out and are very efficient (cost ~1 cycle if no overflow).
Unsigned overflow is defined, signed overflow isn't.
Strong type checking should be able to detect this kind of overflow statically. Probably not practical in the kinds of software involved though.