[rust-dev] Integer overflow, round -2147483648

Lars Bergstrom larsberg at mozilla.com
Tue Jun 24 07:57:53 PDT 2014


> On Jun 23, 2014, at 7:16 PM, John Regehr <regehr at cs.utah.edu> wrote:
> 
>> I do think Rust should exposed either `checked { }` or operators for
>> checked arithmetic along with an opt-in lint to deny the unchecked
>> operators. You can opt-out of a lint for a function/impl/module after
>> opting into it at a higher scope.
>> 
>> I'm just making it clear that doing this by default would make Rust
>> slower than Java by default, and I think that would kill off interest in
>> the language. I know I wouldn't be interested anymore.
> 
> Sure, I think there are a lot of reasonable options here, and I agree that speed and predictability are super important for Rust.
> 
> One thing I personally think is very important (not for 1.0, but eventually) is to make it possible -- no need for this to be mandatory -- to get overflow checking for the default integer type.  I'm happy to use a special compiler flag or whatever to get this.  The only controversial thing this requires from the core language is a way for me to tell the compiler which integers (a tiny subset, typically) should have wrapping behavior.

If the compiler option to have integer overflow checking were available, I'm 99% sure that we'd require having it enabled for Servo and all of its dependencies. We would probably only relax that requirement within the equivalent of an `unsafe` block where the performance had shown up as an issue, leaving it clearly labeled so that we could easily identify any code that touches it.

> I realize that safe integers are available and that operator overloading goes a lot ways towards making these palatable, but the fact is that everyone is an optimist when it comes to integer overflow bugs.  People just do not think they're going to get bitten.

At a quick glance, in Mozilla's bugzilla there were 88 public browser bugs resolved/verified related to integer overflow issues + 14 currently under investigation. I don't have access to the tippy-top secret databases of security vulnerabilities, but I'd be pretty shocked if there weren't a few that would get past Rust's memory safety model (e.g., because they're passed down to WebCL, WebRTC libraries, a graphics driver, etc.). A quick glance at the WebKit bugzilla showed 11 similarly resolved bugs and a couple currently under investigation.

While that isn't a lot, if I have to choose between the Servo team spending time casually optimizing corner cases or adding an LLVM pass (in ways we already know - this isn't "A Sufficiently Smart Compiler"-level hackery here) vs. handling panicked high-priority security issues in a browser we are trying to claim is "safe," I'll pick the former every time.
- Lars



More information about the Rust-dev mailing list