4 ms·

> Since overflow cannot cause crashes or data races (outside of unsafe code), we can skip these checks without endangering Rust's core value proposition of safe

by jzwinck 12y ago

> Since overflow cannot cause crashes or data races (outside of unsafe code), we can skip these checks without endangering Rust's core value proposition of safe systems programming. Whenever checks are disabled, overflow will yield an undefined value (this is distinct from--and much more limited than--the "undefined behavior" you get in C). This is too dismissive of the seriousness of problems that might occur due to unchecked overflow [1]. [1] https://news.ycombinator.com/item?id=8690206 https://news.ycombinator.com/item?id=8690206

kibwen 12y ago
Nobody is attempting to dismiss the idea that overflow is a problem. The fact that we have had innumerable discussions over this very topic should be indication that this is something that Rust cares about, and will be investigating further in the future as compiler support improves (it's not stated outright, but I suspect the fact that overflow yields an "undefined value" is to leave open the possibility of making overflow saturating-by-default sometime in the future without breaking backwards-compatibility, if the performance hit turns out to be acceptable).
- angersock 12y ago
  Saturating overflow? Egads. What's the problem with just trapping overflow by default again? I'm willing to bet many would happily take the performance hit in favor of having a genuinely safe language.
  - kibwen 12y ago
    1. Overflow doesn't cause memory unsafety in Rust, so trying to imply that it's not a genuinely safe language is incorrect. 2. Even if it did, saturating on overflow is exactly as safe as trapping, and has the added benefit of not introducing an untold number of new ways that your program can panic. 3. Trapping on overflow is oversold as a solution to logical errors because you're still opening yourself up to approximately four billion (or 18 quintillion, depending on width) invalid states before your program bites it. If you want a real solution, stick numeric bounds in your type system.
    - sunfish 12y ago
      It sounds like there is confusion between "trapping" and "wrapping" here. "Introducing 4 billion [...]" sounds like a description of the failure modes of wrapping. In contrast, trapping interrupts the flow of the program, so there are zero "invalid states before your program bites it". Trapping seems like a very appealing solution, from the perspective of application code. The primary downsides are that it's somewhat inefficient in today's popular hardware architectures, and it's somewhat inconvenient for optimizers.
      - kibwen 12y ago
        They are invalid states because, with the exception of indexing into an array or doing something else directly related to the memory size of your platform, INT_MAX is never the point at which the value stored in a fixed-width numeric type ceases to make sense. If I have an RPG where I want to cap a character's stats at 99 (been playing too much Dark Souls, I think...) yet fail to implement a manual sanity check, I open myself to the possibility of, at best, 128-99=29 invalid states (and in the worst-case, if I used a u64, I get the aforementioned 18 quintillion invalid states). My program is invalid during this time, but trapping arithmetic can't help me. This is why I said that to actually solve this problem you need numeric bounds in your type system.
        modeless 12y ago
        You are correct that trapping on overflow isn't useful as a substitute for bounds checking on variables that have a well-defined maximum and/or minimum value. However, that doesn't mean overflow checking is useless. It remains extremely useful to prevent silent incorrect behavior when an otherwise unbounded value hits implementation limits. In fact, I'd call it essential to any language that aims for the level of robustness Rust aspires to.
        kibwen 12y ago
        I'm not trying to say it's useless. :) I think it's very valuable, but we need to be honest about its shortcomings rather than viewing it as a sheer win. A language like Rust is completely worthless if it's not fast; we've got a dozen languages that are already memory-safe and within 2x the speed of C. Given that Rust's plethora of safety mechanisms mean that numeric overflow can't cause memory unsafety, I completely understand why they would take the practical route rather than the theoretically-perfect route (even if, as predicted, they get crucified for it by armchair language designers).

by jzwinck 12y ago

kibwen 12y ago

Nobody is attempting to dismiss the idea that overflow is a problem. The fact that we have had innumerable discussions over this very topic should be indication that this is something that Rust cares about, and will be investigating further in the future as compiler support improves (it's not stated outright, but I suspect the fact that overflow yields an "undefined value" is to leave open the possibility of making overflow saturating-by-default sometime in the future without breaking backwards-compatibility, if the performance hit turns out to be acceptable).

angersock 12y ago
Saturating overflow? Egads. What's the problem with just trapping overflow by default again? I'm willing to bet many would happily take the performance hit in favor of having a genuinely safe language.
- kibwen 12y ago
  1. Overflow doesn't cause memory unsafety in Rust, so trying to imply that it's not a genuinely safe language is incorrect. 2. Even if it did, saturating on overflow is exactly as safe as trapping, and has the added benefit of not introducing an untold number of new ways that your program can panic. 3. Trapping on overflow is oversold as a solution to logical errors because you're still opening yourself up to approximately four billion (or 18 quintillion, depending on width) invalid states before your program bites it. If you want a real solution, stick numeric bounds in your type system.
  - sunfish 12y ago
    It sounds like there is confusion between "trapping" and "wrapping" here. "Introducing 4 billion [...]" sounds like a description of the failure modes of wrapping. In contrast, trapping interrupts the flow of the program, so there are zero "invalid states before your program bites it". Trapping seems like a very appealing solution, from the perspective of application code. The primary downsides are that it's somewhat inefficient in today's popular hardware architectures, and it's somewhat inconvenient for optimizers.
    - kibwen 12y ago
      They are invalid states because, with the exception of indexing into an array or doing something else directly related to the memory size of your platform, INT_MAX is never the point at which the value stored in a fixed-width numeric type ceases to make sense. If I have an RPG where I want to cap a character's stats at 99 (been playing too much Dark Souls, I think...) yet fail to implement a manual sanity check, I open myself to the possibility of, at best, 128-99=29 invalid states (and in the worst-case, if I used a u64, I get the aforementioned 18 quintillion invalid states). My program is invalid during this time, but trapping arithmetic can't help me. This is why I said that to actually solve this problem you need numeric bounds in your type system.
      - modeless 12y ago
        You are correct that trapping on overflow isn't useful as a substitute for bounds checking on variables that have a well-defined maximum and/or minimum value. However, that doesn't mean overflow checking is useless. It remains extremely useful to prevent silent incorrect behavior when an otherwise unbounded value hits implementation limits. In fact, I'd call it essential to any language that aims for the level of robustness Rust aspires to.
        kibwen 12y ago
        I'm not trying to say it's useless. :) I think it's very valuable, but we need to be honest about its shortcomings rather than viewing it as a sheer win. A language like Rust is completely worthless if it's not fast; we've got a dozen languages that are already memory-safe and within 2x the speed of C. Given that Rust's plethora of safety mechanisms mean that numeric overflow can't cause memory unsafety, I completely understand why they would take the practical route rather than the theoretically-perfect route (even if, as predicted, they get crucified for it by armchair language designers).