
A tale of two’s complement - adwn
http://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062
======
100k
This seems like a pretty good compromise on integer overflow. I'm happy to see
the Rust core team taking the problem seriously after seeing so much
discussion about it.

------
modeless
I love the compromise on integer overflow. Default overflow checking in debug
mode will keep most Rust programs free of overflow, and that should ensure
that if hardware designers ever come to their senses and implement free
hardware overflow traps, Rust code can enable them without issue.

~~~
millstone
Rust's position is reasonable, but it won't keep most programs free of
overflow. Overflow and underflow bugs typically require malicious input to
expose; casual testing usually doesn't encounter them.

Also, in release builds they promise an undefined value, not undefined
behavior. By my reading, hardware-assisted overflow checks cannot log errors
or do anything else useful under this policy. (Probably saturating arithmetic
is best, since it's most likely to trigger an out-of-bounds error.)

Their saving grace is the other safety checks (e.g. bounds checking), and
their assertion that "we reserve the right to make checking stricter in the
future" which enables them to strengthen this policy.

------
ant6n
I wonder how many bits the int would have on an 8088.

~~~
heinrich5991
If it's the 20-bit address stuff, `int` would have 32 bits on that platform.
(The same as `intptr_t` in C.)

------
jzwinck
> Since overflow cannot cause crashes or data races (outside of unsafe code),
> we can skip these checks without endangering Rust's core value proposition
> of safe systems programming. Whenever checks are disabled, overflow will
> yield an undefined value (this is distinct from--and much more limited than
> --the "undefined behavior" you get in C).

This is too dismissive of the seriousness of problems that might occur due to
unchecked overflow [1].

[1]
[https://news.ycombinator.com/item?id=8690206](https://news.ycombinator.com/item?id=8690206)

~~~
kibwen
Nobody is attempting to dismiss the idea that overflow is a problem. The fact
that we have had innumerable discussions over this very topic should be
indication that this is something that Rust cares about, and will be
investigating further in the future as compiler support improves (it's not
stated outright, but I suspect the fact that overflow yields an "undefined
value" is to leave open the possibility of making overflow saturating-by-
default sometime in the future without breaking backwards-compatibility, if
the performance hit turns out to be acceptable).

~~~
angersock
Saturating overflow? Egads.

What's the problem with just trapping overflow by default again?

I'm willing to bet many would happily take the performance hit in favor of
having a genuinely safe language.

~~~
kibwen
1\. Overflow doesn't cause memory unsafety in Rust, so trying to imply that
it's not a genuinely safe language is incorrect.

2\. Even if it did, saturating on overflow is exactly as safe as trapping, and
has the added benefit of not introducing an untold number of new ways that
your program can panic.

3\. Trapping on overflow is oversold as a solution to logical errors because
you're still opening yourself up to approximately four billion (or 18
quintillion, depending on width) invalid states before your program bites it.
If you want a real solution, stick numeric bounds in your type system.

~~~
angersock
So, I'm not really caring about memory safety--there are lots of reasons _to
care_ , mind you, but that's not my concern.

It's that, quite simply, not being able to easily catch integer arithmetic
errors is a really annoying flaw in a language that needs to do systems work--
especially if it's used in places where, say, you are decoding buffers or
handling IO or basically getting data from an untrusted/faulty source.

It could even be done as a basic addition to the standard library...I frankly
don't care _how_. It's just that it is a really obvious wart to anyone that's
ever had to do safe integer work in the lingua-franca of languages, C.

Just because the program doesn't _crash_ doesn't mean it's being _useful_.

~~~
kibwen
As mentioned in the OP, support for checked arithmetic does exist in the
stdlib, and has for ages.

