[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Sun Jun 22 14:58:11 PDT 2014


On 22/06/14 05: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?

Rust's goal has been to bring modern language features to the systems
programming world (sum types, traits, pattern matching) and make the
necessary sacrifices to achieve memory safety. Rust isn't intended to be
all things to all people. Most of the complexity budget has been spent
providing memory safety without making performance sacrifices.

Bounds checks are already one of the most serious barriers to adoption
as a replacement for C and C++. A lot of effort will need to go into
exposing safe APIs (like iterators) for sidestepping this overhead. At
the moment, the unchecked indexing methods are required in many cases to
avoid a large performance loss relative to C and the code ends up being
far uglier than it would have been in C.

Rust could provide checked arithmetic, but it can't make use of it in
the standard libraries. It wouldn't improve the safety of the language
because any performance critical low-level code using `unsafe` is going
to want to avoid paying the cost of bounds checks.

It's not simply a language issue, because libraries would need to expose
methods with and without the overflow checks whenever they're doing
arithmetic with the parameters.

> 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.
> 
> A fairly simple rule is that a check for overflow only needs to occur
> before the incorrect result may have externally visible side effects.
> Ada’s rule even lets you go a step further and remove overflow checks
> from loops  in some cases (without violating control dependence of the
> eventual overflowing operation).
> 
> One model like this that has been proposed for C/C++ is the “As
> Infinitely Ranged” model (see
> http://www.cert.org/secure-coding/tools/air-integer-model.cfm), where
> operations either give the result that would be correct if integers had
> infinite precision, or cause a trap. This allows for more optimizations
> to be performed, and although it is questionable to me whether they
> preserved control dependence of overflow behavior in all cases, they
> report a 5.5% slowdown on SPEC2006 with GCC 4.5 (compared to a 13%
> slowdown with more plentiful checks) using a very naive implementation.
> A lot of those checks in SPEC2006 could probably just be eliminated if
> the language itself distinguished between overflow-trapping and
> overflow-permissive operations. If a compiler optimizer understood the
> semantics of potentially trapping integer operations better (or at all),
> it could reduce the overhead of the checks.
> 
> I know that some people don’t want to require new compiler techniques
> (or are afraid of relying on something outside of the scope of what LLVM
> can handle today), but it would be unfortunate for Rust to make the
> wrong decision here based on such incidental details rather than what is
> actually possible.

Graydon was always adamant that the language should use proven
techniques and should avoid depending on a non-existent compiler
optimization or immature research.

For a language calling itself pragmatic, it has certainly spent a great
deal of time getting to 1.0 and already ventures a fair bit outside of
proven techniques (lifetimes).

The focus should be on releasing an elegant language with memory safety
and competitive performance with C++. Adding new features to the
language at this point rather than refining the existing ones would be a
huge mistake. A feature like checked arithmetic or tail call elimination
can and should go through experiments behind feature gates, but it
doesn't belong in a 1.0 release.

If you don't agree with the fundamental language design at this point,
that's too bad because it's 6 months away from 1.0 and you're too late.

-------------- 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/20140622/abd2136c/attachment.sig>


More information about the Rust-dev mailing list