Arithmetic overflow froze my machine!


A while ago there was a discussion about whether rust should leave arithmetic overflow checks in release code by default. As a data point: Racer just hit what I think is an overflow bug which caused somebody’s windows machine to become unusable while they were editing some code. They ended up hard-resetting.

        for _ in 0..((pos - start)/128) { result.push_str(buffer); }

In this case I think pos was 254, start was 255 and the expression type was type usize so this resulted in a very large Vec ‘result’. Compiling racer in debug mode results in ‘arithmetic operation overflowed’.

A couple of questions:

For racer, what’s the best way to turn on overflow checking in release builds built by cargo?

And for future projects: is there a good way to turn on overflow checking by default, but then disable it in a small subset of code?

Thanks v much!



Use explicit methods to avoid overflow checking: 1u32.wrapping_sub(2) and so on.

I think arithmetic overflow checks are governed by the rustc flag -C debug-assertions=true/false, which you can also set in cargo profiles.

For me, the overflow checks are a godsend for ensuring correct code. It requires that you can try out the project in that mode though, and maybe optimizations + overflow checks is a good way to test racer. Maybe you can set up to have travis/integration tests run the tests in such a mode too.