4 ms·

> It only does so for debug mode. In release mode, it uses modular arithmetic. So it's still treated as an error, just one that has a predictable fallback. I'm

> It only does so for debug mode. In release mode, it uses modular arithmetic. So it's still treated as an error, just one that has a predictable fallback. I'm really not sure how that's much different from `-fsanitize=undefined`. Broken code is broken, even if it breaks in a predictable manner. Now if the modular arithmetic had been enshrined as the expected behavior without being treated like an error to be caught, it'd be another matter.

marcosdumay 3y ago
An error does not rewrite your entire code on the assumption that it can not happen. Signed overflow is not an error in C.
- deleted 3y ago
  [deleted]
- jstimpfle 3y ago
  That should just be a matter of a compiler knob, no? Such as -fsanitize=undefined (which is the sledge hammer, but there could be more fine grained ones).
  - imtringued 3y ago
    It's not. There is no sanitizer on embedded platforms and it turns out, I only use C on embedded platforms, which for me means the UB sanitizer doesn't exist.
    - shrimp_emoji 3y ago
      Also, that flag enables only unreliable detection of the issue. It won't catch it 100% of the time. :D It also interferes with other flags and checkers like Valgrind and adds bloat to the executable as a bonus.
- Chabsff 3y ago
  I meant error "in the code". A chunk of C that causes a signed overflow has an error in it. Seemingly, so does Rust code according to the behavior described in the post I was replying to. My point is that I question how big is the value gain from having a predictable fallback when we are already within the realm of "this code is considered wrong". This isn't unlike the various arguments against the value of compiler warnings. That being said, I agree that it's preferable in general, but the difference seems rather marginal to me. That is, within the context of what I'm replying to. I wouldn't be surprised if Rust had a few additional tricks up its sleeve to address this.
  - marcosdumay 3y ago
    You really mean the usual C reasoning of "if this program has an error, what difference does it makes if it returns the wrong value or formats the main disk" (With an implicit "I see none" added on the end)? Because a caught static error, a runtime error, a wrong value, and C's UB are completely different beasts.
    - uecker 3y ago
      I think modular behavior at run-time is actively dangerous. It is not memory-unsafe, but still unsafe. Having it trap would better. For C, you can tell the compiler to trap for signed overflow.
      - marcosdumay 3y ago
        IMO, that's a job for the type system. But if you can only have one option, clearly an error is the best one. Anyway, none of those are anything nearly as damaging as C's UB. All of them are reasonable, on the literal sense that you can reason about them, anticipate what your program may do, and defend against the problem (or shrug it off and claim "it doesn't matter here"). You can do neither with by the spec C.
        uecker 3y ago
        I do not think C's UB is damaging. As I said, you instruct the compiler to insert a trap and then it is not unsafe. Example: https://godbolt.org/z/Kvrrx19Pa https://godbolt.org/z/Kvrrx19Pa The UB in the spec is exactly what makes safe use possible without enforcing it everywhere, which is not feasible for C.

marcosdumay 3y ago

An error does not rewrite your entire code on the assumption that it can not happen. Signed overflow is not an error in C.

deleted 3y ago
[deleted]
jstimpfle 3y ago
That should just be a matter of a compiler knob, no? Such as -fsanitize=undefined (which is the sledge hammer, but there could be more fine grained ones).
- imtringued 3y ago
  It's not. There is no sanitizer on embedded platforms and it turns out, I only use C on embedded platforms, which for me means the UB sanitizer doesn't exist.
  - shrimp_emoji 3y ago
    Also, that flag enables only unreliable detection of the issue. It won't catch it 100% of the time. :D It also interferes with other flags and checkers like Valgrind and adds bloat to the executable as a bonus.
Chabsff 3y ago
I meant error "in the code". A chunk of C that causes a signed overflow has an error in it. Seemingly, so does Rust code according to the behavior described in the post I was replying to. My point is that I question how big is the value gain from having a predictable fallback when we are already within the realm of "this code is considered wrong". This isn't unlike the various arguments against the value of compiler warnings. That being said, I agree that it's preferable in general, but the difference seems rather marginal to me. That is, within the context of what I'm replying to. I wouldn't be surprised if Rust had a few additional tricks up its sleeve to address this.
- marcosdumay 3y ago
  You really mean the usual C reasoning of "if this program has an error, what difference does it makes if it returns the wrong value or formats the main disk" (With an implicit "I see none" added on the end)? Because a caught static error, a runtime error, a wrong value, and C's UB are completely different beasts.
  - uecker 3y ago
    I think modular behavior at run-time is actively dangerous. It is not memory-unsafe, but still unsafe. Having it trap would better. For C, you can tell the compiler to trap for signed overflow.
    - marcosdumay 3y ago
      IMO, that's a job for the type system. But if you can only have one option, clearly an error is the best one. Anyway, none of those are anything nearly as damaging as C's UB. All of them are reasonable, on the literal sense that you can reason about them, anticipate what your program may do, and defend against the problem (or shrug it off and claim "it doesn't matter here"). You can do neither with by the spec C.
      - uecker 3y ago
        I do not think C's UB is damaging. As I said, you instruct the compiler to insert a trap and then it is not unsafe. Example: https://godbolt.org/z/Kvrrx19Pa https://godbolt.org/z/Kvrrx19Pa The UB in the spec is exactly what makes safe use possible without enforcing it everywhere, which is not feasible for C.