[rust-dev] Integer overflow, round -2147483648

Jerry Morrison jhm456 at gmail.com
Tue Jun 24 17:03:11 PDT 2014

On Tue, Jun 24, 2014 at 11:58 AM, Daniel Micay <danielmicay at gmail.com>

> That's why I support adding attributes but turning wrapping on overflow
> on and off for a scope. You can indicate whether wrapping is considered
> correct in that scope, meaning you either expect it to wrap or you have
> audited it (just as you would an `unsafe` block) and determined that it
> can not overflow. This doesn't introduce implementation defined
> behaviour or new language dialects via compiler flags.
> Rust has been consistently opposed to adding compiler switches changing
> the meaning of the code. The metadata belongs *in the code* itself, and
> you are free to flip wrapping on/off for whatever reason in the code
> itself.

I agree except there are 3 cases even if the compiler treats two of them
the same. Whatever order Gábor listed them, there's:

(1) Wraparound is correct here, e.g. in a hash function. This is important
information to programmers, debuggers, analysis tools, and testing tools
even if the compiler treats it identically with #2.

(2) [Default] Wraparound would be incorrect but don't check at runtime to
save the performance costs. This includes the audited case -- Tools should
still consider overflow here bad. (What's the distinction between "bug" and
"error"?) Even we audited this code, maybe we goofed in our audit and maybe
later code changes invalidated some of our assumptions.

(3) Wraparound is incorrect and do check at runtime. Hopefully the language
would not require precise exceptions for these integer overflow checks and
future development work would test techniques like AIR.

On ergonomics:

* It sounds good to specify #2 and #3 with annotations so the choice can be
made and changed on a whole scope, and yes, so the information is in the
source code for all programmers and tools to see.

Q: Is there a practical way to scope it larger than a function?
Q: Could testing tools temporarily change the annotation's behavior to make
#[unchecked] act as #[checked]?
Q: Could debugging tools temporarily change the annotation's behavior into
a precise exception to aid debugging?

* #1 is separate -- that code won't change to/from #2 or #3. An annotation
sounds reasonable although wraparound operators sound better since they're
more visible and not accidentally changed when editing annotations.

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

More information about the Rust-dev mailing list