5 ms·

A tale of two’s complement

90 points by adwn 12y ago

ant6n 12y ago
I wonder how many bits the int would have on an 8088.
- Narishma 12y ago
  Is there a reason it wouldn't be 16 bits like in C?
- heinrich5991 12y ago
  If it's the 20-bit address stuff, `int` would have 32 bits on that platform. (The same as `intptr_t` in C.)
- rynes 12y ago
  The Intel 8088 has an 8 bit bus, and 8 bit registers. The size of an integer is 16 bits.
100k 12y ago
This seems like a pretty good compromise on integer overflow. I'm happy to see the Rust core team taking the problem seriously after seeing so much discussion about it.
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.
modeless 12y ago
I love the compromise on integer overflow. Default overflow checking in debug mode will keep most Rust programs free of overflow, and that should ensure that if hardware designers ever come to their senses and implement free hardware overflow traps, Rust code can enable them without issue.
- millstone 12y ago
  Rust's position is reasonable, but it won't keep most programs free of overflow. Overflow and underflow bugs typically require malicious input to expose; casual testing usually doesn't encounter them. Also, in release builds they promise an undefined value, not undefined behavior. By my reading, hardware-assisted overflow checks cannot log errors or do anything else useful under this policy. (Probably saturating arithmetic is best, since it's most likely to trigger an out-of-bounds error.) Their saving grace is the other safety checks (e.g. bounds checking), and their assertion that "we reserve the right to make checking stricter in the future" which enables them to strengthen this policy.

90 points by adwn 12y ago

ant6n 12y ago

I wonder how many bits the int would have on an 8088.

Narishma 12y ago
Is there a reason it wouldn't be 16 bits like in C?
heinrich5991 12y ago
If it's the 20-bit address stuff, `int` would have 32 bits on that platform. (The same as `intptr_t` in C.)
rynes 12y ago
The Intel 8088 has an 8 bit bus, and 8 bit registers. The size of an integer is 16 bits.

100k 12y ago

This seems like a pretty good compromise on integer overflow. I'm happy to see the Rust core team taking the problem seriously after seeing so much discussion about it.

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.

modeless 12y ago

I love the compromise on integer overflow. Default overflow checking in debug mode will keep most Rust programs free of overflow, and that should ensure that if hardware designers ever come to their senses and implement free hardware overflow traps, Rust code can enable them without issue.

millstone 12y ago
Rust's position is reasonable, but it won't keep most programs free of overflow. Overflow and underflow bugs typically require malicious input to expose; casual testing usually doesn't encounter them. Also, in release builds they promise an undefined value, not undefined behavior. By my reading, hardware-assisted overflow checks cannot log errors or do anything else useful under this policy. (Probably saturating arithmetic is best, since it's most likely to trigger an out-of-bounds error.) Their saving grace is the other safety checks (e.g. bounds checking), and their assertion that "we reserve the right to make checking stricter in the future" which enables them to strengthen this policy.