[rust-dev] Integer overflow, round -2147483648
danielmicay at gmail.com
Sat Jun 21 14:42:05 PDT 2014
On 21/06/14 05:21 PM, Vadim Chugunov wrote:
> My 2c:
> The world is finally becoming security-conscious, so I think it is a
> only matter of time before architectures that implement zero-cost
> integer overflow checking appear. I think we should be ready for it
> when this happens. So I would propose the following practical solution
> (I think Gabor is also leaning in favor of something like this):
ARM and x86_64 aren't going anywhere and it's too late for trap on
overflow to be part of the baseline instruction set. It's far from a
sure thing that it would even be added. The small x86_64 instructions
are all used up so it's impossible to add trap on overflow without more
expensive instruction decoding and bloated code size.
Anyway, trapping would *not* map to how Rust currently deals with logic
errors. It would need to give up on unwinding for logic errors in order
to leverage these kinds of instructions. The alternative is depending on
asynchronous unwinding support and OS-specific handling for the trapping
instructions (SIGFPE like division by zero?).
Processors already implement a trap on division by zero but Rust is
currently not able to take advantage of it... until we're doing it for
division, there's no indication that we'll be able to do it for other
> 1. Declare that regular int types (i8, u8, i32, u32, ...) are
> Check them for overflow in debug builds, maybe even in optimized builds
> on platforms where the overhead is not too egregious. There should
> probably be a per-module performance escape hatch that disables overflow
> checks in optimized builds on all platforms. On zero-cost overflow
> checking platforms, the checks would of course always be on.
> Also, since we are saving LLVM IR in rlibs for LTO, it may even be
> possible to make this a global (i.e. not just for the current crate)
> compile-time decision.
If they're not defined as wrapping on overflow, how *are* they defined?
It does have to be defined as something, even if that means an arbitrary
result left up to the implementation. The result must be consistent
between reads to maintain memory safety.
> 2. Introduce new wrapping counterparts of the above for cases when
> wrapping is actually desired.
> If we don't do this now, it will be much more painful later, when large
> body of Rust code will have been written that does not make the
> distinction between wrapping and non-wrapping ints.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Rust-dev