[rust-dev] Integer overflow, round -2147483648

Vadim Chugunov vadimcn at gmail.com
Sun Jun 22 16:43:32 PDT 2014

Makes sense, but I am curious, how do you see adding this post-1.0?   Would
- add overflow-checked int types and tell everybody to use them instead of
the default ones from that point on
- declare that in Rust2 integers are overflow-checked, and have everybody
port their Rust1 code.  (Well, in reality, I would expect that most
existing code would just continue to work, but some testing will be needed).
Both sound somewhat painful.

I still think it would be a good idea to provide explicitly wrapping int
types (which aren't the default ones) from get-go and point out in
documentation that those are the ones to be used when writing hashes, etc.
Even if they are just aliases of the default int types.  If nothing else,
this will allow people to document in their code whether the ints were
supposed to wrap around or not.


On Sun, Jun 22, 2014 at 4:12 PM, Patrick Walton <pcwalton at mozilla.com>

> On 6/22/14 2:12 PM, Cameron Zwarich wrote:
>> For some applications, Rust’s bounds checks and the inability of rustc
>> to eliminate them in nontrivial cases will already be too much of a
>> performance sacrifice. What do we say to those people? Is it just that
>> memory safety is important because of its security implications, and
>> other forms of program correctness are not?
>> I am wary of circling around on this topic again, but I feel that the
>> biggest mistake in this discussion js that checked overflow in a
>> language requires a potential trap on every single integer operation.
>> Languages like Ada (and Swift, to a lesser extent), allow for slightly
>> imprecise exceptions in the case of integer overflow.
> I believe that it is possible that the overhead of integer overflow will
> be negligible in the future, and that paper is exciting to me too! But I
> feel that:
> 1. Integer overflow is primarily a security concern when it compromises
> memory safety. Quoting OWASP [1], emphasis mine:
> "An integer overflow condition exists when an integer, which has not been
> properly sanity checked, is used in the *determination of an offset or size
> for memory allocation, copying, concatenation, or similarly*."
> Other features in Rust, such as bounds checks, unsigned indexing, and the
> borrow check, defend against the memory safety problems. So the benefits of
> defending against memory safety are likely to be quite different in Rust
> from in C. It's a question of costs versus benefits, as always.
> 2. Signed integer overflow is not undefined behavior in Rust as it is in
> C. This mitigates some of the more frightening risks associated with it.
> 3. The As-If-Infinitely-Ranged paper is research. Like all research, the
> risk of adopting integer overflow checks is somewhat high; it might still
> not work out to be acceptable in practice when we've exhausted all
> potential compiler optimizations that it allows. That risk has to be
> compared against the potential reward, which is likely to be lesser in Rust
> than in C because of the reasons outlined in (1) and (2).
> 4. We have a pretty tight shipping schedule at this point: 1.0, which is
> the backwards compatible release, is on track to be released this year. We
> are making excellent progress on backwards incompatible language changes
> (closed 10 out of 45 issues over the past 2 weeks!), but we must be
> consciously fighting scope creep in order to release a product.
> 5. It's not clear to me that integer overflow cannot be added backwards
> compatibly: we can lexically scope checked arithmetic in much the same way
> C# lexically scopes unchecked arithmetic. It's not in line with Rust's
> philosophy of safe-by-default, but saying that we might introduce a safer
> opt-in version of Rust in the future strikes me as a fairly pragmatic
> compromise, and one that is not without successful precedent: for example,
> C, has, for all intents and purposes, successfully shed the baggage of its
> "variables without an annotated type default to int" design mistake via a
> bog-standard compiler warning.
> For these reasons, I'm pretty comfortable with not making any changes for
> 1.0, and deferring this issue to later.
> Patrick
> [1]: https://www.owasp.org/index.php/Integer_overflow
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140622/cf0fba4b/attachment.html>

More information about the Rust-dev mailing list