Tracking issue for Integer Overflow (RFC 560)

[aturon]

RFC: rust-lang/rfcs#560
Final text: https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md

List of tasks to accomplish:

• Optional error checking on +, -, * Implement arithmetic overflow changes #22532
• Implement wrapping_add, wrapping_sub, wrapping_mul from the WrappingOps trait Implement arithmetic overflow changes #22532
• Optional error checking on /, % (we currently check unconditionally; see signed division has undefined behaviour on overflow #8460)
• Implement wrapping_div, wrapping_rem from the WrappingOps trait (see arith-oflo: what is semantics of divide int::MIN.wrapped_div(-1) rfcs#964) Fill in missing parts of Integer overflow API  #24420
• Optional error checking on << and >> overflowing-checking for rhs of shift operators #23536
• Implement wrapping_lshift, wrapping_rshift from the WrappingOps trait
  • (renamed to wrapping_shl, wrapping_shr.) Fill in missing parts of Integer overflow API  #24420
• Optional error checking on unary - for signed values Check for overflow in arithmetic negation #24500
• Implement wrapping_neg from the WrappingOps trait Fill in missing parts of Integer overflow API  #24420
• Lint for use of one of the potentially fallible operations in an unsafe fn or fn containing unsafe blocks
  • Note that the use need not occur in an unsafe block, just a fn containing unsafe blocks
• Option to forcibly enable overflow checking
• Overflow checking disabled by default when optimizations are enabled - rustc: Add a debug_assertions #[cfg] directive #22980
• Fix const_eval to do overflow checking based on declared type rather than u64/i64 (on all of the above cases) - arithmetic-overflow checks during const-eval #23863 (constant evaluation should not mask overflow for cases that are otherwise checked #22531)

---

• Optional error checking on as (see http://internals.rust-lang.org/t/on-casts-and-checked-overflow/1710/15)
• Implement wrapping_as_X methods from the WrappingOps trait
  • (above two are no longer needed since as has been [re]defined to never panic).
• consider saturating cast operations Add a saturating_cast between integers #23596

[aturon]

cc @nikomatsakis

[aturon]

cc @Aatch

[glaebhoerl]

(cc #20795)

[pnkfelix]

(cc #22532)

[pnkfelix]

@aturon does a -Z flag count for "Option to forcibly enable overflow checking" ?

[aturon]

@pnkfelix I'm not sure; I wasn't the one who updated this with a checklist. @nikomatsakis @alexcrichton?

[alexcrichton]

I would personally consider a -Z flag to fit the bill

[nikomatsakis]

Interesting. I consider a -Z flag adequate for this bug, perhaps,
but not a good overall solution. However, it seems like having a good
set of public flags around this falls under
#22492

On Wed, Mar 04, 2015 at 05:27:27PM -0800, Alex Crichton wrote:

I would personally consider a -Z flag to fit the bill

---

Reply to this email directly or view it on GitHub:
#22020 (comment)

[codyps]

May also want to add:

• Implement wrapping_negate method from the WrappingOps trait

(or whatever it should be named)

To match with:

• Optional error checking on unary -

[pnkfelix]

for consistency with the Shl trait etc in core:ops, we probably should name the wrapping shift methods wrapping_shl, etc

(of course it won't be a 100% correspondence anyway; e.g. we implement Shl for every kind of integer RHS, but I suspect supporting that might be silly in the WrappingOps trait. Well, we'll see.)