On 24/06/14 10:57 AM, Lars Bergstrom wrote:
>> On Jun 23, 2014, at 7:16 PM, John Regehr <reg...@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.This has nothing to do with `unsafe`, considering it to be `unsafe` would be incorrect. I doubt Servo would use it, because at that point I don't understand why you wouldn't just be writing the browser in Scala as it would perform better. There has been a strong consensus to avoid jamming things unrelated to memory safety into `unsafe`, such as catching reference cycles. >> 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. We've have very few memory safety bugs caused by integer overflow, and I haven't seen these occur in places where the performance hit of the integer overflow checking would have been acceptable. The only one I can think of off the top of my head is the size overflow in the ~[T] `push` function. The overflow check there had to be done very carefully, as one check reduces the performance of pushing to a vector by ~20% but adding in two checks resulted in a >200% loss in performance. There are numerous calculations in that function, so automatic integer overflow checking would destroy it. On the other hand, we've had countless memory safety bugs caused by exceptions. The difficulty of writing exception safe code is high, and it's likely the most common safety issue in the Rust codebase. Yet I don't see the Servo developers arguing against having exceptions in Rust, in fact they're the strongest supporters of the feature. > 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. You can continue living in your fantasy world, but in the real world no compiler pass is going to make a language with overflow checking perform as well as Java/Scala. You can keep repeating this misinformation, but it doesn't make it any more true. You haven't explained how this is going to cause security issues in Rust, when the language is guaranteed to be memory safe outside of `unsafe` blocks. The `unsafe` blocks are low-level, performance critical code where unnecessary overflow checks are always going to be acceptable, so the feature has next to no value in terms of memory safety. It would help in identifying correctness issues in other cases, but it wouldn't actually be any more correct to throw an exception than to overflow. In either case, it's a bug, and in neither case is it a memory safety issue.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
