Hacker News Reader

Comment by pcwalton | Hacker News Reader

The undefined behavior exploitation that compilers do is entirely reasonable and not something that we should go back on. Defining overflow as wrapping, for example, would be bad for security because it means we couldn't check it with UBSan.

Rather than rehashing the same arguments I've made over and over, I'll just link to parts of a Twitter thread where Daniel Micay argues eloquently that keeping the sources of UB that we have today as they are is important:

https://twitter.com/DanielMicay/status/1118017342644998144

https://twitter.com/DanielMicay/status/1118034688935747584

View on HN

> 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”.

The 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.

This isn't the reason why signed overflow is UB in C.

As 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.

You 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").

The 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.

> Defining overflow as wrapping, for example, would be bad for security because it means we couldn't check it with UBSan.

no, because unsigned overflow is valid and yet ubsan is able to check for it with -funsigned-integer-overflow (and I caught so many bugs like this)

Reply on news.ycombinator.com