-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for Integer Overflow (RFC 560) #22020
Comments
cc @Aatch |
(cc #20795) |
(cc #22532) |
@aturon does a |
@pnkfelix I'm not sure; I wasn't the one who updated this with a checklist. @nikomatsakis @alexcrichton? |
I would personally consider a |
Interesting. I consider a On Wed, Mar 04, 2015 at 05:27:27PM -0800, Alex Crichton wrote:
|
May also want to add:
(or whatever it should be named) To match with:
|
for consistency with the (of course it won't be a 100% correspondence anyway; e.g. we implement |
@aturon to be 100% clear, the lint that is described here:
is a reference to the lint section of the RFC, and therefore is talking about linting for uses of Right? |
@pnkfelix I didn't make the detailed list here -- I would check with @nikomatsakis |
@pnkfelix correct |
(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.) |
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. |
@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: 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. |
@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 |
Fill in missing parts of Integer overflow API See todo list at #22020
I think all of the backwards compatibility issues have now been resolved. |
Not sure how important that lint was. Nominating for discussion at next triage mtg. |
(oops I added a "triage:" comment and then deleted it, but of course rust-highfive cannot turn back time.) |
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. |
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. |
I believe this has basically all been implemented, so closing. |
(Well there is the lint that was listed in the description, but its questionable whether we actually need/want that...) |
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:
+
,-
,*
Implement arithmetic overflow changes #22532wrapping_add
,wrapping_sub
,wrapping_mul
from theWrappingOps
trait Implement arithmetic overflow changes #22532/
,%
(we currently check unconditionally; see signed division has undefined behaviour on overflow #8460)wrapping_div
,wrapping_rem
from theWrappingOps
trait (see arith-oflo: what is semantics of divideint::MIN.wrapped_div(-1)
rfcs#964) Fill in missing parts of Integer overflow API #24420<<
and>>
overflowing-checking for rhs of shift operators #23536wrapping_lshift
,wrapping_rshift
from theWrappingOps
traitwrapping_shl
,wrapping_shr
.) Fill in missing parts of Integer overflow API #24420-
for signed values Check for overflow in arithmetic negation #24500wrapping_neg
from theWrappingOps
trait Fill in missing parts of Integer overflow API #24420unsafe
fn or fn containingunsafe
blocksunsafe
block, just a fn containingunsafe
blocksu64
/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 onas
(see http://internals.rust-lang.org/t/on-casts-and-checked-overflow/1710/15)Implementwrapping_as_X
methods from theWrappingOps
traitas
has been [re]defined to never panic).The text was updated successfully, but these errors were encountered: