[rust-dev] Integer overflow, round -2147483648

Vadim Chugunov 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
optimized builds.
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
> operations.
>

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
for now.



> > 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
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/1fa43357/attachment.html>


More information about the Rust-dev mailing list