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 +, -, * #22532
• Implement wrapping_add, wrapping_sub, wrapping_mul from the WrappingOps trait #22532
• Optional error checking on /, % (we currently check unconditionally; see #8460)
• Implement wrapping_div, wrapping_rem from the WrappingOps trait (see rust-lang/rfcs#964) #24420
• Optional error checking on << and >> #23536
• Implement wrapping_lshift, wrapping_rshift from the WrappingOps trait
  • (renamed to wrapping_shl, wrapping_shr.) #24420
• Optional error checking on unary - for signed values #24500
• Implement wrapping_neg from the WrappingOps trait #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 - #22980
• Fix const_eval to do overflow checking based on declared type rather than u64/i64 (on all of the above cases) - #23863 (#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 #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)

[jmesmon]

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.)

[pnkfelix]

@aturon to be 100% clear, the lint that is described here:

Lint for use of one of the above operations in an unsafe fn or fn containing unsafe blocks

is a reference to the lint section of the RFC, and therefore is talking about linting for uses of {+, -, *, <<, >>, as <integral-type>} in a function with unsafe blocks, and not about linting for uses of the newly added WrappingOps methods in such functions...

Right?

[aturon]

@pnkfelix I didn't make the detailed list here -- I would check with @nikomatsakis

[freebroccolo]

cc me

[nikomatsakis]

@pnkfelix correct

[pnkfelix]

(regarding shift behavior, I thought the (old) discussion on #1877 was interesting. In particular there is a semi-open question of whether we should follow Java in our fallback behavior for the RHS of a shift, or if we should just pass it directly to LLVM, and live with underspecification in general.)

[glaebhoerl]

If we weren't willing to live with underspecification around the result of arithmetic overflows (with checks off), then it seems we should be consistent and be the same way with respect to shifts also.

[pnkfelix]

@glaebhoerl yes that is a reasonable conclusion to draw.

In any case, I have left a prominent spot in the code indicating what lines to uncomment to follow Java's approach; see:
https://github.com/rust-lang/rust/pull/23536/files#diff-88ce76a36e25f7f0d19bc4cdd58ee1b8R2584

Update: To be clear: I originally wrote and tested the code with those masks in place. I only commented them out after reading #1877. It should be trivial to uncomment them if that's what we want.

[pnkfelix]

@glaebhoerl okay, due to #10183 and #23551, my mind is now completely turned around on this issue: As far as I can tell, we must ensure that the input-rhs is in the half-open range [0, sizeof(lhs_t)*8), because otherwise LLVM can produce nonsense.

[pnkfelix]

I think all of the backwards compatibility issues have now been resolved.

[pnkfelix]

Not sure how important that lint was. Nominating for discussion at next triage mtg.

[pnkfelix]

(oops I added a "triage:" comment and then deleted it, but of course rust-highfive cannot turn back time.)

[pnkfelix]

My intent was to nominate, but also suggest a P-medium assignment for the remaining work here. I will put back the P-backcompat-lang label.

[pnkfelix]

triage: Remaining work is P-medium (at most).... lint may only qualify as a "nice to have" at this point, it is unclear how important it will be.

[alexcrichton]

I believe this has basically all been implemented, so closing.

[pnkfelix]

(Well there is the lint that was listed in the description, but its questionable whether we actually need/want that...)