[rust-dev] Integer overflow, round -2147483648
vadimcn at gmail.com
Sat Jun 21 15:43:18 PDT 2014
On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <danielmicay at gmail.com> wrote:
> 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.
I am sure they will figure out a way if this feature becomes a competitive
advantage. Whether this will be by adding a prefix to existing
instructions, or by creating a new CPU mode I don't know. One thing Intel
could do rather easily, would be to spruce up the INTO instruction, which
is currently neglected and slow because noone's using it. It's a chicken
and egg problem: why would they invest time into improving a feature that
nobody can take advantage of?
If Wikipedia is to be believed, MIPS already has ints with overflow
checking. Some brand-new architectures <http://millcomputing.com/docs/>
are heading this way too.
And, as I said, if it's too slow, overflow check will be elided in
We should, however, invent a way to harass developers who overflow their
ints,- to provide an incentive to think about which kind of int is needed.
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
Since division overflow already needs to be dealt with, I don't see a
problem with making addition overflow do the same thing.
Eventually it might be useful to have a third kind of ints, that return
Option<TResult>, however until Rust has support for monads, I don't think
these would be very useful. Intrinsic functions would probably be enough
> > 1. Declare that regular int types (i8, u8, i32, u32, ...) are
> > non-wrapping.
> > 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.
In checked builds they'll trap, just like division by zero. In unchecked
builds, the result is "undefined". But, of course, in practice, they will
just wrap around.
> > 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.
> > Vadim
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev