6 ms·

Lol, when C does it, it's "unsafe". When Rust does it, it's "modular"!

by xscott 3y ago

deleted 3y ago
[deleted]
mathiaskindberg 3y ago
For anyone wondering about the term "modular": > In mathematics, modular arithmetic is a system of arithmetic for integers, where numbers "wrap around" when reaching a certain value, called the modulus. The modern approach to modular arithmetic was developed by Carl Friedrich Gauss in his book Disquisitiones Arithmeticae, published in 1801. https://en.wikipedia.org/wiki/Modular_arithmetic https://en.wikipedia.org/wiki/Modular_arithmetic
- nuancebydefault 3y ago
  Modular/modulus (and also twos complement) is a natural feature of most CPUs. It comes natural by the way logic counters work in hardware. C enforces that by not touching that logic. Rust is the same in that respect. Python on the other hand treats integers as objects with a virtually unlimited amount of digits. That said, float/double precision and logic is still CPU dependent and is used as-is for most languages.
marcosdumay 3y ago
It's astonishing the number of people defending the C "ideals" that demonstrate ignorance about what C actually does. (Is it artificial,in order to willingly miss the point?) Only some of the integral types in C are modular. If they all where, it wouldn't be a problem.
- xscott 3y ago
  No, what's astonishing is that now that every CPU worth using has 2's complement for signed integers, the compiler writers are still embracing undefined behavior in the name of piddly optimizations. I was tempted to specify "unsigned" to ward off the obnoxious pedants, and I see that I should have. C really should be a portable assembly language by now. A very small non-breaking change to the standard, and C's arithmetic would be the same as Rust's.
  - marcosdumay 3y ago
    > No, what's astonishing is that now that every CPU worth using has 2's complement for signed integers, the compiler writers are still embracing undefined behavior in the name of piddly optimizations. Yeah, that's also astonishing. Anyway, I've stopped blaming the C developers by now. I just assume they have the goal of killing the language and moving people into a more ergonomic alternative. I don't know their true intentions, but this has been a very predictive assumption. (I guess any definition of any UB would be non-breaking, so yeah, they could fix all of the language.)
    - xscott 3y ago
      > I just assume they have the goal of killing the language Sadly, that's my conclusion too. I really wish there was a good "portable assembly language", and maybe that'll be something that targets WASM.
  - deleted 3y ago
    [deleted]
- cozzyd 3y ago
  then use -fwrapv if that's what you want...
nicoburns 3y ago
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.

Lol, when C does it, it's "unsafe". When Rust does it, it's "modular"!

by xscott 3y ago

Lol, when C does it, it's "unsafe". When Rust does it, it's "modular"!

deleted 3y ago

[deleted]

mathiaskindberg 3y ago

For anyone wondering about the term "modular": > In mathematics, modular arithmetic is a system of arithmetic for integers, where numbers "wrap around" when reaching a certain value, called the modulus. The modern approach to modular arithmetic was developed by Carl Friedrich Gauss in his book Disquisitiones Arithmeticae, published in 1801. https://en.wikipedia.org/wiki/Modular_arithmetic https://en.wikipedia.org/wiki/Modular_arithmetic

nuancebydefault 3y ago
Modular/modulus (and also twos complement) is a natural feature of most CPUs. It comes natural by the way logic counters work in hardware. C enforces that by not touching that logic. Rust is the same in that respect. Python on the other hand treats integers as objects with a virtually unlimited amount of digits. That said, float/double precision and logic is still CPU dependent and is used as-is for most languages.

marcosdumay 3y ago

It's astonishing the number of people defending the C "ideals" that demonstrate ignorance about what C actually does. (Is it artificial,in order to willingly miss the point?) Only some of the integral types in C are modular. If they all where, it wouldn't be a problem.

xscott 3y ago
No, what's astonishing is that now that every CPU worth using has 2's complement for signed integers, the compiler writers are still embracing undefined behavior in the name of piddly optimizations. I was tempted to specify "unsigned" to ward off the obnoxious pedants, and I see that I should have. C really should be a portable assembly language by now. A very small non-breaking change to the standard, and C's arithmetic would be the same as Rust's.
- marcosdumay 3y ago
  > No, what's astonishing is that now that every CPU worth using has 2's complement for signed integers, the compiler writers are still embracing undefined behavior in the name of piddly optimizations. Yeah, that's also astonishing. Anyway, I've stopped blaming the C developers by now. I just assume they have the goal of killing the language and moving people into a more ergonomic alternative. I don't know their true intentions, but this has been a very predictive assumption. (I guess any definition of any UB would be non-breaking, so yeah, they could fix all of the language.)
  - xscott 3y ago
    > I just assume they have the goal of killing the language Sadly, that's my conclusion too. I really wish there was a good "portable assembly language", and maybe that'll be something that targets WASM.
- deleted 3y ago
  [deleted]
cozzyd 3y ago
then use -fwrapv if that's what you want...

nicoburns 3y ago

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.