[rust-dev] Integer overflow, round -2147483648
vadimcn at gmail.com
Tue Jun 24 17:39:22 PDT 2014
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping and non-wrapping calculations in the
On Tue, Jun 24, 2014 at 5:03 PM, Jerry Morrison <jhm456 at gmail.com> wrote:
> 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
> 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.
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev