[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Mon Jun 23 13:55:39 PDT 2014

On 23/06/14 03:59 PM, Cameron Zwarich wrote:
> On Jun 22, 2014, at 4:12 PM, Patrick Walton <pcwalton at mozilla.com> wrote:
>> 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*.”
> It doesn’t sound like that definition would consider this bug an “integer overflow condition”, but it certainly seems like one to me:
> http://minimaxir.com/2013/05/stones-of-jordan/

Rust's usage of `unsafe` is restricted to low-level performance critical
code and wrapping existing C libraries. I doubt that checked overflow is
going to be used in the former case since it's performance critical code
at the core of the standard libraries and in the latter case it's up to
the C code to get it right.

>> 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).
> Ada adopted a similar model before many of the people working on Rust were even born, so the basic idea isn’t research. The researchy aspect of the AIR paper is retroactively applying it to C. There are probably some unanswered questions regarding aggressive optimizations in the face of this model, but the same goes for many other design choices of Rust.
>> 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.
> I had to deal with bugs caused by K&R C last year, and ABIs for new architectures like ARM64 are designed to be compatible with K&R C, even if it complicates the implementation, so I don’t necessarily agree that the removal of baggage has been quick.
> We can probably correct integer operations later (even if it breaks backwards compatibility to some extent), but it’s disappointing that a systems language from ~2013 can’t learn from all of the correctness lessons of a systems language from 1983.

It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.

I don't see why having either `checked { }` or explicitly checked
operators along with a lint is a problem. It will be backwards
compatible and won't interfere with the out-of-the-box performance, and
there won't be any significant drawbacks for people who want the feature.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140623/99d21f83/attachment.sig>

More information about the Rust-dev mailing list