“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory

Re:“What the Hardware Does” Is Not What Your Program Does: U... by pcwalton on Sunday July 14, 2019 @10:43PM (#20437738)

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.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by userbinator on Monday July 15, 2019 @07:25AM (#20439744)

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.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Monday July 15, 2019 @07:04AM (#20439625)

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

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by enedil on Monday July 15, 2019 @01:17AM (#20438325)

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

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @02:19AM (#20438571)

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.

[ Parent | on HN ]