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 operations. > 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. > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
