News for hackers. Stuff that matters.
Re:Catching integer overflows in C by CryZe on Wednesday August 22, 2018 @01:17AM (#17816488)
The point is rather that Rust has a bunch of methods on integer for dealing with overflows in a variety of ways, like saturating, wrapping or returning an Option with a None value on overflow (there's also one that returns a tuple with the carry).
Re:Catching integer overflows in C by millstone on Wednesday August 22, 2018 @02:56AM (#17816869)
That's all good but it misses my point: the one redeeming quality of C's integer overflow non-semantics is that it unlocks further compiler optimizations, and that's the mode which AFAICT Rust doesn't support.

For example, a for loop from 0-through-N (N:i32) will execute N times in C, but N-or-infinity times in Rust. That small difference of infinity controls how the loop condition is tested, whether it can be turned into a simple counter or not.

Re:Catching integer overflows in C by jcranmer on Wednesday August 22, 2018 @09:13AM (#17818428)
> For example, a for loop from 0-through-N (N:i32) will execute N times in C, but N-or-infinity times in Rust.

Eh, not quite true. If N is a 64-bit or an unsigned integer but your loop index is a signed 32-bit integer, then you will have this behavior. In Rust, the idiomatic for loop will have the index variable always be the same size as the condition variable, which prevents the infinity case from happening. In C, if you have a 64-bit condition but a 32-bit unsigned loop index variable, you get the N-or-infinity case as well.

In other words, if your language is subtly redesigned to make you jump through hoops to do things like have mismatched integer types in for loops, then the need to rely on undefined behavior to reclaim that performance is lessened.