“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 nemetroid on Sunday July 14, 2019 @03:43PM (#20435504)

> But, for a counter-point: what is an example of a code/algorithm that not only uses undefined behaviour (i.e. relies on it in order to compile to fast, optimized code), but also couldn't possibly be rewritten to eliminate undefined behaviour (while keeping the same speed)?

Any code that handles signed integers is going to assume that overflow/underflow does not happen.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by aarongolliver on Sunday July 14, 2019 @04:09PM (#20435660)

Spent the week trying to figure out how to reimplement __builtin_add_overflow (et al) on Windows and boy is it a chore. The previous implementer had literally just used operator+ in a function called "safe_add" and I was dumbstruck.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by steveklabnik on Sunday July 14, 2019 @03:48PM (#20435533)

Note that this isn’t UB in Rust.

[ Parent | on HN ]