4 ms·

> The Rust developers have adopted a hybrid solution where integer overflows trap in debug builds and wrap in optimized builds. This is not a solution. The p

> The Rust developers have adopted a hybrid solution where integer overflows trap in debug builds and wrap in optimized builds. This is not a solution. The production binaries and the test binaries run on different data. We try as programmers and release engineers to try to get the test environment to match production, but it's hard to do right, and takes constant upkeep. Trapping should be the default, and disabled only by special user intent, which optimization flags are not.

dbaupp 10y ago
Many (maybe most) languages are OK with changing behaviour/code between debug and release builds, e.g. disabling `assert`s and even the optimisations themselves. Of course, this is suboptimal in some cases, and thus providing a way to disable it is good and thus rustc has -C debug-assertions=on, and a currently-unstable flag to control just the overflow checks themselves. Seguing from that first flag, Rust makes it explicit when an assertion is OK to omit by providing both debug_assert! (removed in release) and assert! (never removed), so I guess Rust is in a middle ground that's the reverse of the middle ground of a language like, say, Swift, which removes assertions but not overflow checks in its default optimised build.
- SamReidHughes 10y ago
  Swift has release-mode assertions, they're done with precondition().
  - dbaupp 10y ago
    You are correct, but my point was implicitly that the default thing people reach for is assert, especially since the name precondition sounds like it is only ok to call at the start of a function.
pcwalton 10y ago
> Trapping should be the default, and disabled only by special user intent, which optimization flags are not. At the cost of making programs slower. For every comment like this we would have 5 comments asking why Rust is slower than C++. Besides, the real solution is memory safety, which Rust does not compromise. Memory safety stops the vast majority of overflow issues from becoming security problems.

dbaupp 10y ago

Many (maybe most) languages are OK with changing behaviour/code between debug and release builds, e.g. disabling `assert`s and even the optimisations themselves. Of course, this is suboptimal in some cases, and thus providing a way to disable it is good and thus rustc has -C debug-assertions=on, and a currently-unstable flag to control just the overflow checks themselves. Seguing from that first flag, Rust makes it explicit when an assertion is OK to omit by providing both debug_assert! (removed in release) and assert! (never removed), so I guess Rust is in a middle ground that's the reverse of the middle ground of a language like, say, Swift, which removes assertions but not overflow checks in its default optimised build.

SamReidHughes 10y ago
Swift has release-mode assertions, they're done with precondition().
- dbaupp 10y ago
  You are correct, but my point was implicitly that the default thing people reach for is assert, especially since the name precondition sounds like it is only ok to call at the start of a function.

pcwalton 10y ago

> Trapping should be the default, and disabled only by special user intent, which optimization flags are not. At the cost of making programs slower. For every comment like this we would have 5 comments asking why Rust is slower than C++. Besides, the real solution is memory safety, which Rust does not compromise. Memory safety stops the vast majority of overflow issues from becoming security problems.