5 ms·
> Defining overflow as wrapping, for example, would be bad for security because it means we couldn't check it with UBSan. You could always write “WrapAroundSan
by tylerhou 7y ago
> Defining overflow as wrapping, for example, would be bad for security because it means we couldn't check it with UBSan.
You could always write “WrapAroundSan”.
- pcwalton 7y agoThe problem is that if you did that then you couldn't check regular C programs anymore, since overflow would be valid. Right now we're in the nice situation in which normal C programs are expected not to exhibit signed overflow. Change that state of affairs and suddenly a lot of obvious mistakes become valid.
- enedil 7y agoThis isn't the reason why signed overflow is UB in C.
- saagarjha 7y agoAs far as I can tell, signed overflow is undefined behavior because when the standard was defined there were a lot of machines where it would trap or do something weird, and for some reason the standards authors did not choose to make it implementation-defined behavior.
- ralfjung 7y agoYou could always say that wrap-around has to either (a) cause SIGILL or (b) return the wrapped-around result. That still allows linting with a sanitizer without involving any UB at all. This is effectively what Rust does (replace "SIGILL" by "panic").
- userbinator 7y agoThe problem is that if you did that then you couldn't check regular C programs anymore, since overflow would be valid. That also means it's possible to write overflow checks easily, and ones that the compiler won't optimise out. Before compilers became UB-crazy, you could write such checks in the most straightforward way, and get exactly what you expected. I'd consider that a far bigger advantage for security than arguing for the existence of a tool whose sole reason for existence seems to be due to the presence of UB in the first place.