4 ms·

C and Rust do very different things in this case. C defines overflow of signed integers to be Undefined Behaviour. Whereas in Rust it either wraps (release mode

C and Rust do very different things in this case. C defines overflow of signed integers to be Undefined Behaviour. Whereas in Rust it either wraps (release mode) or panics (debug mode).

jstimpfle 3y ago
Any specific C compiler could do the same in complete agreement with the C standard. There isn't a guarantee that any given standards-conforming compiler will, but it seems that with Rust there isn't a guarantee what behaviour you get either (it depends on the compile settings). In either language, you can't write code that does signed overflow in a meaningful way (at least not if you use Debug).
- xscott 3y ago
  I agree with your point, but note that Rust does have an ugly way to do it: https://doc.rust-lang.org/std/primitive.i64.html#method.wrapping_add https://doc.rust-lang.org/std/primitive.i64.html#method.wrap... I'd rather just put `-fwrapv` on the command line that clutter my code with crap like that though.
  - nicoburns 3y ago
    > I'd rather just put `-fwrapv` on the command line that clutter my code with crap like that though. The advantage of Rust's way is that it lets you customise addition on a per-operation basis. So you can mix and match wrapping addition with saturating addition, etc.
    - xscott 3y ago
      Yes, I can have functions/methods that do math differently from the default. I could just as easily say that's C's way and mix and match those: int64_t x = add_i64_with_abort_on_debug_and_wrap_on_release(y, z); uint8_t t = add_u8_with_saturation(u, v); I'd prefer the default for the math operators be what all the CPUs currently do, and neither C or Rust promises that.
- deleted 3y ago
  [deleted]
xscott 3y ago
Yes, so fix the C standard... But the compiler guys won't let the anyone fix it, because optimizations. So either A) the optimizations using UB are important, and therefore C is/will-always-be faster than Rust which doesn't have them. Or B) the optimizations using UB are not important and the compiler writers for gcc and clang are wrong. You pick. And of course some insane people advocate for adding undefined behavior to Rust in the name of optimizations. Gross.
deleted 3y ago
[deleted]

C and Rust do very different things in this case. C defines overflow of signed integers to be Undefined Behaviour. Whereas in Rust it either wraps (release mode) or panics (debug mode).

jstimpfle 3y ago

Any specific C compiler could do the same in complete agreement with the C standard. There isn't a guarantee that any given standards-conforming compiler will, but it seems that with Rust there isn't a guarantee what behaviour you get either (it depends on the compile settings). In either language, you can't write code that does signed overflow in a meaningful way (at least not if you use Debug).

xscott 3y ago
I agree with your point, but note that Rust does have an ugly way to do it: https://doc.rust-lang.org/std/primitive.i64.html#method.wrapping_add https://doc.rust-lang.org/std/primitive.i64.html#method.wrap... I'd rather just put `-fwrapv` on the command line that clutter my code with crap like that though.
- nicoburns 3y ago
  > I'd rather just put `-fwrapv` on the command line that clutter my code with crap like that though. The advantage of Rust's way is that it lets you customise addition on a per-operation basis. So you can mix and match wrapping addition with saturating addition, etc.
  - xscott 3y ago
    Yes, I can have functions/methods that do math differently from the default. I could just as easily say that's C's way and mix and match those: int64_t x = add_i64_with_abort_on_debug_and_wrap_on_release(y, z); uint8_t t = add_u8_with_saturation(u, v); I'd prefer the default for the math operators be what all the CPUs currently do, and neither C or Rust promises that.
deleted 3y ago
[deleted]

xscott 3y ago

Yes, so fix the C standard... But the compiler guys won't let the anyone fix it, because optimizations. So either A) the optimizations using UB are important, and therefore C is/will-always-be faster than Rust which doesn't have them. Or B) the optimizations using UB are not important and the compiler writers for gcc and clang are wrong. You pick. And of course some insane people advocate for adding undefined behavior to Rust in the name of optimizations. Gross.

deleted 3y ago

[deleted]