Why does Rust perform integer overflow checks in --release?

Question

I have this piece of simple code:

let val: u8 = 255 + 1;
println!("{}", val);

It is said here that such a code will compile normally if run with the --release flag.

I am running this code via cargo run --release, and I still see the checks:

error: this arithmetic operation will overflow
 --> src/main.rs:2:19
  |
2 |     let val: u8 = 255 + 1;
  |                   ^^^^^^^ attempt to compute `u8::MAX + 1_u8`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

error: could not compile `rust-bin` due to previous error

Am I missing something?

https://doc.rust-lang.org/stable/book/ch03-02-data-types.html#integer-overflow — stefan_aus_hannover, Jan 19 '22 at 18:51
@stefan_aus_hannover how does this book differ from the one I'm reading? — Oleksandr Novik, Jan 19 '22 at 18:55

user4815162342 · Accepted Answer · 2022-01-21T20:01:37.407

The book is slightly imprecise. Overflow is disallowed in both debug and release modes, it's just that release mode omits runtime checks for performance reasons (replacing them with overflow, which CPUs typically do anyway). Static checks are not removed because they don't compromise on performance of generated code. This prints 0 in release mode and panics in debug¹:

let x: u8 = "255".parse().unwrap();
let val: u8 = x + 1;
println!("{}", val);

You can disable the compile-time checks using #[allow(arithmetic_overflow)]. This also prints 0 in release mode and panics in debug:

#[allow(arithmetic_overflow)]
let val: u8 = 255 + 1;
println!("{}", val);

The correct approach is to not depend on this behavior of release mode, but to tell the compiler what you want. This prints 0 in both debug and release mode:

let val: u8 = 255u8.wrapping_add(1);
println!("{}", val);

¹ The example uses "255".parse() because, to my surprise, let x = 255u8; let val = x + 1; doesn't compile - in other words, rustc doesn't just prevent overflow in constant arithmetic, but also wherever else it can prove it happens. The change was apparently made in Rust 1.45, because it compiled in Rust 1.44 and older. Since it broke code that previously compiled, the change was technically backward-incompatible, but presumably broke sufficiently few actual crates that it was deemed worth it. Surprising as it is, it's quite possible that "255".parse::<u8>() + 1 will become a compile-time error in a later release.

Good observation. Theoretically, the compiler can be extended to catch a lot more cases. But, of course, lots of cases could never be predicted at compile time (as I mentioned in my answer). Also, some cases that *could* be detected at compile time would probably cost way too much in terms of compilation speed and/or implementation complexity, so it simply won't be worth it to handle them. As for `"255".parse::()` - that's a rather artificial example. I can't think of many situations where we would want to parse a string literal. — at54321, Jan 19 '22 at 22:38
Note that you can opt-in to runtime overflow checks in release mode by setting `overflow-checks = true` in `[profile.release]` in `Cargo.toml`. doc.rust-lang.org/cargo/reference/profiles.html — pizzapants184, Dec 13 '22 at 22:29

at54321 · Answer 2 · 2022-01-19T18:59:22.973

In your code, the compiler is able to detect the problem. That's why it prevents it even in release mode. In many cases it's not possible or feasible for the compiler to detect or prevent an error.

Just as an example, imagine you have code like this:

let a = b + 5;

Let's say b's value comes from a database, user input or some other external source. It is literally impossible to prevent overflows in cases like that.

Why does Rust perform integer overflow checks in --release?

2 Answers2