On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <danielmi...@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@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
