[rust-dev] Integer overflow, round -2147483648
jhm456 at gmail.com
Sat Jun 21 15:54:31 PDT 2014
I agree with Vadim that the world will inevitably become security-conscious
-- also safety-conscious. We will live to see it unless such a bug causes
nuclear war or power grid meltdown.
When the sea change happens, Rust will either be (A)* the attractive choice
for systems programming* or (B) *obsolete*. Rust already has the leading
position in memory safety for systems programming, so it's lined up to go.
The world desperately needs a C++ replacement for real-time,
safety-critical software before that ever-more-complicated language causes
big disasters. Rust is the only candidate around for that. (Or maybe D, if
its real-time threads can avoid GC pauses.) CACM's recent *Mars Code*
article <http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext> shows
the extremes that JPL has to do to program reliable space probes. Smaller
companies writing automobile engine control systems
and such will soon be looking for a more cost effective approach.
Companies like Intel see so much existing C/C++ software getting by without
overflow safety and conclude it doesn't matter. Let's not let their
rear-view mirror thinking keep us stuck. Eventually customers will demand
better security whether there's a speed penalty or not.
CPU designers could say they've given us so much instruction speed that we
can afford to spend some of it on overflow checking. Fair point. When the
software folks have demonstrated the broad need, Intel can speed it up,
whether by optimizing certain instruction sequences or adding new
The Mill CPU architecture handles overflow nicely and promises much higher
performance, like extending DSP abilities into ordinary software loops like
strncpy(). Whether this one takes off or not is hard to say. That little
company could use a big partner.
On Sat, Jun 21, 2014 at 3:43 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
> On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <danielmicay at gmail.com>
>> 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
> 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
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev