[rust-dev] Integer overflow, round -2147483648

Jerry Morrison jhm456 at gmail.com
Sun Jun 22 17:25:16 PDT 2014

Apologies for adding heat to the discussion. The industry needs to make
progress on security/safety-critical systems, and Rust does a great deal
for that by bringing memory safety to a C/C++ alternative.

This post about hardware traps for integer overflow
<http://blog.regehr.org/archives/1154> is useful, even besides the issue of
the full cost of traps. The post and its discussion explore alternatives.
It links to this conference article about Understanding Integer Overflow in
C/C++ <http://www.cs.utah.edu/~regehr/papers/overflow12.pdf>, which studied
overflow bugs, vulnerabilities, and some overflow-checking techniques. One
technique averaged 44% cost, ranging 0 to 191%. Another averaged 30%,
ranging 0 - 95%. They discovered that "intentional uses of wraparound
behaviors are more common than expected" but hard to find.

The post also links to Wikipedia on Intel MPX
<http://en.wikipedia.org/wiki/Intel_MPX>: Intel is adding x86 extensions to
aid memory safety! I think it's for array bounds checking, but the article
is unclear.

If the choice is a Rust with inconvenient and often unused overflow safety
that kills off C/C++ vs. a Rust with overflow safety that doesn't, I vote
for the former.

The open design questions are ergonomics of checked and wraparound
arithmetic. It'd be great if uses of wraparound arithmetic were explicit.

On Sun, Jun 22, 2014 at 2:05 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> A `Vec<u32>` and `Vec<uw32>` would be entirely distinct types. ...

THAT is a knockout blow for the distinct-types design for wrapping integers.

(BTW is there a use for *signed* wraparound?)

On Sun, Jun 22, 2014 at 2:09 PM, Rick Richardson <rick.richardson at gmail.com>

> ... I would assume that one would really only care about checked math
> during testing and dev.

Alas, that doesn't block security exploits.

On Sun, Jun 22, 2014 at 2:26 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> Rust's design is based on the assumption that performance cannot be
> achieved simply by having highly optimized inner loops. It takes a whole
> program approach to performance by exposing references as first-class
> values and enforcing safety via type-checked lifetimes.
> You can write an efficient low-level loop in Haskell or Swift, but you
> can't build high level safe abstractions without paying a runtime cost.
> If someone isn't interested in this approach, then I have a hard time
> understanding why they would be using Rust.

To move a lot of code from C/C++ to a place that has memory safety and less
error-prone 1970's technology with 1960's macro processing and linking.

For real-time programs, which need predictable response times whether or
not they need high performance (often fixable with faster hardware). Many
of these are embedded devices with small memory.

Maybe Swift will work there but (1) it'll have to go beyond Apple hardware
and OSs, and (2) reference counting has unpredictable delays when freeing a
large network of objects.

On Sun, Jun 22, 2014 at 2:23 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> The set of design compromises made by the language is ill-suited to a
> use case where performance isn't critical.

Is there a web page that lays out Rust's goals, design trade-offs, and
intended uses?

On Sun, Jun 22, 2014 at 2:12 PM, Cameron Zwarich <zwarich at mozilla.com>

> Languages like Ada (and Swift, to a lesser extent), allow for slightly
> imprecise exceptions in the case of integer overflow. ... the “As
> Infinitely Ranged” model ...

> 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)

>From TFA:

> AIR integers do not require precise traps and consequently do not break or
> inhibit most existing optimizations.

Hopefully Apple will contribute its Swift compiler to the LLVM source tree.
That includes overflow detection. Also if needed, they have the ability to
customize their ARM chips and some sway with Intel.

On Sun, Jun 22, 2014 at 2:31 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> If we had compiler switches for ... I think even 2 dialects is too much...

Yes. When one C dialect calls another via dynamic loading, bad things
happen, and there's no debugger on the robot. (Speaking from experience.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140622/5655cb10/attachment.html>

More information about the Rust-dev mailing list