3 ms·

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,

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]