3 ms·

It's surprising and potentially buggy behavior, but that's very different from undefined behavior. To such a degree that I think you honestly might not underst

by Groxx 4mo ago

It's surprising and potentially buggy behavior, but that's very different from undefined behavior. To such a degree that I think you honestly might not understand what it means, and what the risks are around undefined behavior, especially in the presence of an optimizing compiler. As a starter / refresher perhaps, both of these are perfectly permissible and happen in practice with UB, but never with "wrap or panic" / "implementation defined" behavior: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-In-Action/ https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-... This kind of thing is an example of the "time travel" stevekablanik is referring to, stuff that is literally impossible as written, that absolutely no human would consider to be a reasonable execution of the code, but occurs regularly with UB.

kllrnohj 4mo ago
-fsantize=integer and whambo bambo C/C++'s "time traveling UB" is now more consistent, better defined, and safer than Rust's release build behavior. I don't know if Rust will ever attempt to fix this mistake, but I seriously hope they do.
- steveklabnik 4mo ago
  If you're talking about compiler flags, rustc -C overflow-checks=yes or in your project config, [profile.release] overflow-checks = true gives you consistent panics on overflow.
- afdbcreid 4mo ago
  In C/C++ the default behavior, always, is very dangerous UB. Some compilers offer an option for guaranteed wrap-around, and some compilers offer an option for controlled crash. None of them is standardized or the default. In Rust the standard mandates a guaranteed wrap-around or a controlled crash. The default behavior is crashing in debug mode and wrapping-around in release mode, but you can control that with a compiler flag. No matter how you look at it, the Rust behavior is safer. The default behavior? Way better in Rust than in C++. Want a guaranteed wrap-around? In Rust, check. In C++, depending on the compiler. Want a guaranteed crash? In Rust, check. In C++, depending on the compiler. Also worth noting that overflowing has much more severe consequences in C++ than in Rust, due to bounds checks. > I don't know if Rust will ever attempt to fix this mistake It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision.
  - Groxx 4mo ago
    > > I don't know if Rust will ever attempt to fix this mistake > It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision. There's also wrapping_add / saturating_add for anyone concerned about this. Ya want a specific behavior? Just tell the compiler! You can also use the type wrappers so it happens implicitly! https://doc.rust-lang.org/std/num/struct.Saturating.html https://doc.rust-lang.org/std/num/struct.Saturating.html (presumably this is optimizable on hardware that has operators for this, but idk if that happens yet)
    - kllrnohj 4mo ago
      > There's also wrapping_add / saturating_add for anyone concerned about this. Ya want a specific behavior? Just tell the compiler! That is exactly why Rust's behavior for +/- operators is a mistake and wrong. It should always panic and anyone that wants something different can specify that in code, where it's clear and explicit.

by Groxx 4mo ago

kllrnohj 4mo ago

-fsantize=integer and whambo bambo C/C++'s "time traveling UB" is now more consistent, better defined, and safer than Rust's release build behavior. I don't know if Rust will ever attempt to fix this mistake, but I seriously hope they do.

steveklabnik 4mo ago
If you're talking about compiler flags, rustc -C overflow-checks=yes or in your project config, [profile.release] overflow-checks = true gives you consistent panics on overflow.
afdbcreid 4mo ago
In C/C++ the default behavior, always, is very dangerous UB. Some compilers offer an option for guaranteed wrap-around, and some compilers offer an option for controlled crash. None of them is standardized or the default. In Rust the standard mandates a guaranteed wrap-around or a controlled crash. The default behavior is crashing in debug mode and wrapping-around in release mode, but you can control that with a compiler flag. No matter how you look at it, the Rust behavior is safer. The default behavior? Way better in Rust than in C++. Want a guaranteed wrap-around? In Rust, check. In C++, depending on the compiler. Want a guaranteed crash? In Rust, check. In C++, depending on the compiler. Also worth noting that overflowing has much more severe consequences in C++ than in Rust, due to bounds checks. > I don't know if Rust will ever attempt to fix this mistake It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision.
- Groxx 4mo ago
  > > I don't know if Rust will ever attempt to fix this mistake > It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision. There's also wrapping_add / saturating_add for anyone concerned about this. Ya want a specific behavior? Just tell the compiler! You can also use the type wrappers so it happens implicitly! https://doc.rust-lang.org/std/num/struct.Saturating.html https://doc.rust-lang.org/std/num/struct.Saturating.html (presumably this is optimizable on hardware that has operators for this, but idk if that happens yet)
  - kllrnohj 4mo ago
    > There's also wrapping_add / saturating_add for anyone concerned about this. Ya want a specific behavior? Just tell the compiler! That is exactly why Rust's behavior for +/- operators is a mistake and wrong. It should always panic and anyone that wants something different can specify that in code, where it's clear and explicit.