Integer overflow checking

[catamorphism]

At various times, the issue of whether we should enable integer overflow checking (meaning that an integer overflow would be a hard failure at runtime rather than silently wrapping around) has come up; most recently, in this mailing list thread. A more specific example (which I'm about to close in favor of this more general bug) is #2470.

We should decide whether we want to address this form of safety in Rust's semantics.

[sanxiyn]

I propose that we follow a prior work here, namely C# Language Specification, 4th edition, section 14.5.13.

14.5.13 The checked and unchecked operators

The checked and unchecked operators are used to control the overflow-checking context for integral-type arithmetic operations and conversions.

[sanxiyn]

Note that LLVM has overflow intrinsics which compiles to overflow flag and carry flag (if things are aligned). Mono compiles C# checked operators to LLVM overflow intrinsics when it is using the LLVM backend (as a matter of fact, Mono added these to LLVM for their own use).

[bblum]

This came up at lunch today. I'm led to understand that LLVM has a "check if the last operation overflowed" operation, so we should have a corresponding way (primitive or library) to check for it. Sometimes programmers want their operations to overflow (hashing), and sometimes not (pointer arithmetic) --we should leave that decision to them.

[bstrie]

Nominating for Well-Defined.

[emberian]

I don't think it should be part of the language, but a #[check_wrapping] attribute to enable runtime checks could be useful, at least for debugging.

[thestinger]

I've implemented intrinsics + traits for overflow checked add, sub and mul operations in #8408.

For div, checking x / 0 and INT_MIN / -1 are already required to make the non-checked division avoid undefined behaviour, so the checked equivalent would just return an Option instead of failing. I've left that out for now.

[thestinger]

There's now a CheckedDiv trait, so I consider the implementation of the overflow checking itself to be complete.

The built-in integer types are defined as wrapping, but it's now easy to implement an alternate type expanding to a big integer on overflow like the integers in Python. I don't think it makes sense to take any other path, because as long as the type is restricted to fixed-size you need to consider behaviour on overflow.

If there is a specific proposal, that can be opened as an issue. There have been many discussions about this with a consistent consensus that overflow checking is too high a cost to pay. The only full solution is an unbounded integer type, and that comes with the baggage of out-of-memory if you aren't checking inputs.

[thestinger]

I opened #8635 as a replacement for this issue.