5 ms·

I'm not sure if this is what you mean, exactly, but Rust indeed catches this at compile time. https://play.rust-lang.org/?version=stable&mode=debug&edition=202

I'm not sure if this is what you mean, exactly, but Rust indeed catches this at compile time. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7e9037378ca64a7608ca4fee12d34e67 https://play.rust-lang.org/?version=stable&mode=debug&editio... https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=e5478a27f7ce77e76e411f7039671b53 https://play.rust-lang.org/?version=stable&mode=debug&editio...

codedokode 1y ago
I meant panic if during any addition (including in runtime) an overflow occurs.
- trealira 1y ago
  You can set a flag for that: https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks https://doc.rust-lang.org/rustc/codegen-options/index.html#o... By default, they're on during debug mode and off in release mode.
  - codedokode 1y ago
    The choice doesn't make sense because you want the program to always behave correctly and not only during development.
    - lytedev 1y ago
      Eh, maybe. There's a performance tradeoff here and maintainers opted for performance. I'm sure many folks would agree with you that it was the wrong choice, and I'm sure many folks would disagree with you that it was the wrong choice. There are also specific methods for doing *erflow-checked arithmetic if you like.
      - codedokode 1y ago
        Why should there be a performance tradeoff? Because Intel CPU doesn't have add-with-overflow-check instruction, we make our languages less safe?
        genrilz 1y ago
        Actually, the x86 'ADD' instruction automagically sets the 'OF' and 'CF' flags for you for signed and unsigned overflow respectively [0]. So all you need to do to panic would be to follow that with an 'JO' or 'JB' instruction to the panic handling code. This is about as efficient as you could ask for, but a large sequence of arithmetic operations is still going to gum up the branch predictor, resulting in more pipeline stalls. [0]: https://www.felixcloutier.com/x86/add https://www.felixcloutier.com/x86/add
- genrilz 1y ago
  If you obscure the implementation a bit, you can change GP's example to a runtime overflow [0]. Note that by default the checks will only occur when using the unoptimized development profile. If you want your optimized release build to also have checks, you can put 'overflow-checks = true' in the '[profile.release]' section of your cargo.toml file [1]. [0]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=847dc401e16fdff14ecf3724a3b15a93 [1]: https://doc.rust-lang.org/cargo/reference/profiles.html
  - codedokode 1y ago
    This is bad because the program behaves different depending on build flags. What's the point of having "use unsafe addition" flag, and having it enabled by default? Rust developers made a poor choice. They should have made a special function for unchecked addition and have "+" operator always panic on overflow.
    - genrilz 1y ago
      The point I'm sure was to prevent the checks from incurring runtime overhead in production. Even in release mode, the overflow will only wrap rather than trigger undefined behavior, so this won't cause memory corruption unless you are writing unsafe code that ignores the possibility of overflow. The checks being on in the debug config means your tests and replications of bug reports will catch overflow if they occur. If you are working on some sensitive application where you can't afford logic bugs from overflows but can afford panics/crashes, you can just turn on checks in release mode. If you are working on a library which is meant to do something sensible on overflow, you can use the wide variety of member functions such as 'wrapping_add' or 'checked_add' to control what happens on overflow regardless of build configuration. Finally, if your application can't afford to have logic bugs from overflows and also can't panic, you can use kani [0] to prove that overflow never happens. All in all, it seems to me like Rust supports a wide variety of use cases pretty nicely. [0]: https://github.com/model-checking/kani https://github.com/model-checking/kani
- tialaramex 1y ago
  Why do you want a panic? Shift left. Overflow can be rejected at compile time for a price that you might be able to afford - generality. Just insist that the programmer prove that overflow can't occur, and reject programs where the programmer couldn't or wouldn't do this.
  - deleted 1y ago
    [deleted]
  - codedokode 1y ago
    Programmer has other things to do. Computer or CPU should do the checks.

codedokode 1y ago

I meant panic if during any addition (including in runtime) an overflow occurs.

trealira 1y ago
You can set a flag for that: https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks https://doc.rust-lang.org/rustc/codegen-options/index.html#o... By default, they're on during debug mode and off in release mode.
- codedokode 1y ago
  The choice doesn't make sense because you want the program to always behave correctly and not only during development.
  - lytedev 1y ago
    Eh, maybe. There's a performance tradeoff here and maintainers opted for performance. I'm sure many folks would agree with you that it was the wrong choice, and I'm sure many folks would disagree with you that it was the wrong choice. There are also specific methods for doing *erflow-checked arithmetic if you like.
    - codedokode 1y ago
      Why should there be a performance tradeoff? Because Intel CPU doesn't have add-with-overflow-check instruction, we make our languages less safe?
      - genrilz 1y ago
        Actually, the x86 'ADD' instruction automagically sets the 'OF' and 'CF' flags for you for signed and unsigned overflow respectively [0]. So all you need to do to panic would be to follow that with an 'JO' or 'JB' instruction to the panic handling code. This is about as efficient as you could ask for, but a large sequence of arithmetic operations is still going to gum up the branch predictor, resulting in more pipeline stalls. [0]: https://www.felixcloutier.com/x86/add https://www.felixcloutier.com/x86/add
genrilz 1y ago
If you obscure the implementation a bit, you can change GP's example to a runtime overflow [0]. Note that by default the checks will only occur when using the unoptimized development profile. If you want your optimized release build to also have checks, you can put 'overflow-checks = true' in the '[profile.release]' section of your cargo.toml file [1]. [0]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=847dc401e16fdff14ecf3724a3b15a93 [1]: https://doc.rust-lang.org/cargo/reference/profiles.html
- codedokode 1y ago
  This is bad because the program behaves different depending on build flags. What's the point of having "use unsafe addition" flag, and having it enabled by default? Rust developers made a poor choice. They should have made a special function for unchecked addition and have "+" operator always panic on overflow.
  - genrilz 1y ago
    The point I'm sure was to prevent the checks from incurring runtime overhead in production. Even in release mode, the overflow will only wrap rather than trigger undefined behavior, so this won't cause memory corruption unless you are writing unsafe code that ignores the possibility of overflow. The checks being on in the debug config means your tests and replications of bug reports will catch overflow if they occur. If you are working on some sensitive application where you can't afford logic bugs from overflows but can afford panics/crashes, you can just turn on checks in release mode. If you are working on a library which is meant to do something sensible on overflow, you can use the wide variety of member functions such as 'wrapping_add' or 'checked_add' to control what happens on overflow regardless of build configuration. Finally, if your application can't afford to have logic bugs from overflows and also can't panic, you can use kani [0] to prove that overflow never happens. All in all, it seems to me like Rust supports a wide variety of use cases pretty nicely. [0]: https://github.com/model-checking/kani https://github.com/model-checking/kani
tialaramex 1y ago
Why do you want a panic? Shift left. Overflow can be rejected at compile time for a price that you might be able to afford - generality. Just insist that the programmer prove that overflow can't occur, and reject programs where the programmer couldn't or wouldn't do this.
- deleted 1y ago
  [deleted]
- codedokode 1y ago
  Programmer has other things to do. Computer or CPU should do the checks.