[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Sun Jun 22 15:23:08 PDT 2014

On 22/06/14 05:48 PM, Masklinn wrote:
> On 2014-06-22, at 23:31 , Daniel Micay <danielmicay at gmail.com> wrote:
>> On 22/06/14 05:09 PM, Rick Richardson wrote:
>>> Apologies if this has been suggested, but would it be possible to have a
>>> compiler switch that can add runtime checks and abort on
>>> overflow/underflow/carry for debugging purposes, but the default
>>> behavior is no check?  IMO this would be the best of both worlds,
>>> because I would assume that one would really only care about checked
>>> math during testing and dev.
>> You would need to build an entirely separate set of standard libraries
>> with checked overflow.
> From my understanding, everything would be built with checked overflow
> (unless explicitly disabled/bypassed), and the overflow check could be
> disabled at compile-time/.
> I don't think that's a good solution, but that's what Swift's `-Ofast`
> does, it completely removes a number of checks (including overflow
> checking), essentially making the language unsafe but much faster.
> As a side-question, were the performances of ftrapv (in clang) ever
> actually tested? There were some discussion on testing the impact
> in Firefox, but that ended up with GCC's ftrapv being broken and
> not doing anything, and Firefox not working with clang -ftrapv.

It's important to note that `-ftrapv` only adds checks to signed types
and doesn't work with GCC. You need to pass both
`-fsanitize=signed-integer-overflow` and
`-fsanitize=unsigned-integer-overflow` to clang.

> I've not seen any numbers since, just lots of assertions that
> it's far too slow to be an option.

Here's a benchmark of random level generation that made the rounds on
/r/rust and #rust already:


Here is the result with `clang -O3 C.c`:

./a.out 10 &> /dev/null  0.20s user 0.00s system 99% cpu 0.205 total

Here is the result with `clang -O3 -fsanitize=signed-integer-overflow

./a.out 10 &> /dev/null  0.31s user 0.00s system 98% cpu 0.313 total

So in a real world use case consistently partly of integer arithmetic,
it's an absolutely acceptable 50% increase in running time. At that
point, Rust would be a much slower language than Java by default and no
one would use it.

-------------- 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/00e8107f/attachment.sig>

More information about the Rust-dev mailing list