5 ms·

And unsigned overflow is also error-in-debug, overflow-in-release with Rust. If you want wrapping arithmetic, you have to ask for it. In C, unsigned overflow al

And unsigned overflow is also error-in-debug, overflow-in-release with Rust. If you want wrapping arithmetic, you have to ask for it. In C, unsigned overflow always wraps, so even though you can compile with overflow checks, there's no way to distinguish unsigned arithmetic that is supposed to vs not supposed to wrap.

MaxBarraclough 6y ago
Sounds sensible. To quote John Regehr: > Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap. • https://blog.regehr.org/archives/1401 https://blog.regehr.org/archives/1401
- saagarjha 6y ago
  I actually dislike Rust's "wrap in production" default, tbh. It strikes a strange balance: "we care about performance in release mode but we are also going to check and make sure this code does specific things on overflow".
  - ChrisSD 6y ago
    I'm not sure I follow. In release mode it does the most performant thing by default. In debug mode and tests it catches potential problems with using this default. Either way there are explicit methods for doing wrapped, checked or saturating operations in every mode.
    - saagarjha 6y ago
      Undefined behavior on overflow is always the most performant, followed closely by "the result is unspecified". Wrapping is less performant because it often forces the implementation to actually wrap if the behavior is observable, which might be extra work (e.g. i32) or interfere with loop optimizations.
      - MaxBarraclough 6y ago
        Undefined behaviour isn't an option for Safe Rust, where the impossibility of invoking undefined behaviour is the whole point. Non-deterministic unspecified values aren't in keeping with the Safe Rust philosophy either. I imagine throw-on-overflow is slower than wrap-on-overflow. C# can be configured to throw an exception when an int is overflowed, [0] but this behaviour isn't the default and is rarely used (typically it uses wrap-on-overflow). I imagine it might have a significant performance impact, but I'm not sure. In a language like SPARK Ada, intended for formal verification, you can insist upon a rigorous proof that unintended overflow can never occur. That isn't an option for Safe Rust, at least not without significant breakthroughs in tooling. [0] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/checked-and-unchecked https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
        bluGill 6y ago
        Perhaps, but I often know via information not available to the compiler (it might be to a SPARK proof) that overflow won't happen and I don't want to check for it.
        deleted 6y ago
        [deleted]
        nicoburns 6y ago
        That option's available in Rust on a per opration basis if you want it, it's just not the default
        MaxBarraclough 6y ago
        Programmers can't be trusted to do this kind of free-form reasoning correctly, as attested by the unending stream of security vulnerabilities arising from undefined behaviour in C and C++ codebases. The push for safe languages is motivated by pragmatism, not theoretical purity.
        bluGill 6y ago
  - __s 6y ago
    Am important thing to remember is that even with wrapping Rust maintains memory safety Still, I agree, I prefer consistent semantics between dev/prod as much as possible. Especially since there's methods to have checked/wrapping/etc arithmetic, so I can always go to those if I want the other behavior Thankfully, this behavior is a flag which you can personally configure to be consistent across dev/prod: https://doc.rust-lang.org/cargo/reference/profiles.html https://doc.rust-lang.org/cargo/reference/profiles.html It does make sense when interpreting wrapping checks in dev as debug assertions
  - dathinab 6y ago
    > "we care about performance in release mode but we are also going to check and make sure this code does specific things on overflow". More like: > "integer overflow checks are a painful/unacceptable performance degradation for some use-cases, but we still want to cough over-/under-flow bugs during testing" Anyway luckily you can just enable integer overflow checks in release builds, which is not a uncommon setup in use-cases like server code.

MaxBarraclough 6y ago

Sounds sensible. To quote John Regehr: > Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap. • https://blog.regehr.org/archives/1401 https://blog.regehr.org/archives/1401

saagarjha 6y ago
I actually dislike Rust's "wrap in production" default, tbh. It strikes a strange balance: "we care about performance in release mode but we are also going to check and make sure this code does specific things on overflow".
- ChrisSD 6y ago
  I'm not sure I follow. In release mode it does the most performant thing by default. In debug mode and tests it catches potential problems with using this default. Either way there are explicit methods for doing wrapped, checked or saturating operations in every mode.
  - saagarjha 6y ago
    Undefined behavior on overflow is always the most performant, followed closely by "the result is unspecified". Wrapping is less performant because it often forces the implementation to actually wrap if the behavior is observable, which might be extra work (e.g. i32) or interfere with loop optimizations.
    - MaxBarraclough 6y ago
      Undefined behaviour isn't an option for Safe Rust, where the impossibility of invoking undefined behaviour is the whole point. Non-deterministic unspecified values aren't in keeping with the Safe Rust philosophy either. I imagine throw-on-overflow is slower than wrap-on-overflow. C# can be configured to throw an exception when an int is overflowed, [0] but this behaviour isn't the default and is rarely used (typically it uses wrap-on-overflow). I imagine it might have a significant performance impact, but I'm not sure. In a language like SPARK Ada, intended for formal verification, you can insist upon a rigorous proof that unintended overflow can never occur. That isn't an option for Safe Rust, at least not without significant breakthroughs in tooling. [0] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/checked-and-unchecked https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
      - bluGill 6y ago
        Perhaps, but I often know via information not available to the compiler (it might be to a SPARK proof) that overflow won't happen and I don't want to check for it.
        deleted 6y ago
        [deleted]
        nicoburns 6y ago
        That option's available in Rust on a per opration basis if you want it, it's just not the default
        MaxBarraclough 6y ago
        Programmers can't be trusted to do this kind of free-form reasoning correctly, as attested by the unending stream of security vulnerabilities arising from undefined behaviour in C and C++ codebases. The push for safe languages is motivated by pragmatism, not theoretical purity.
        bluGill 6y ago
- __s 6y ago
  Am important thing to remember is that even with wrapping Rust maintains memory safety Still, I agree, I prefer consistent semantics between dev/prod as much as possible. Especially since there's methods to have checked/wrapping/etc arithmetic, so I can always go to those if I want the other behavior Thankfully, this behavior is a flag which you can personally configure to be consistent across dev/prod: https://doc.rust-lang.org/cargo/reference/profiles.html https://doc.rust-lang.org/cargo/reference/profiles.html It does make sense when interpreting wrapping checks in dev as debug assertions
- dathinab 6y ago
  > "we care about performance in release mode but we are also going to check and make sure this code does specific things on overflow". More like: > "integer overflow checks are a painful/unacceptable performance degradation for some use-cases, but we still want to cough over-/under-flow bugs during testing" Anyway luckily you can just enable integer overflow checks in release builds, which is not a uncommon setup in use-cases like server code.