undefined | Better HN

0 pointsjstimpfle2y ago0 comments

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).

0 comments

3 comments · 1 top-level

xscott2y ago· 2 in thread

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.wrap...

I'd rather just put `-fwrapv` on the command line that clutter my code with crap like that though.

nicoburns2y 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.

xscott2y 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.

j / k navigate · click thread line to collapse