-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Properly detect overflow in Instance ± Duration. #44220
Properly detect overflow in Instance ± Duration. #44220
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
@bors: r+ Looks great, thanks! |
📌 Commit abc11c3 has been approved by |
…hould-panic, r=alexcrichton Properly detect overflow in Instance ± Duration. Fix #44216. The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic. The reason #44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second. Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
💔 Test failed - status-travis |
|
@alexcrichton Failure should be fixed in ef8c204: diff --git a/src/libstd/time/mod.rs b/src/libstd/time/mod.rs
index 5b893505b3..bd96f2133e 100644
--- a/src/libstd/time/mod.rs
+++ b/src/libstd/time/mod.rs
@@ -498,7 +498,7 @@ mod tests {
let dur = dur.duration();
assert!(a > b);
assert_almost_eq!(b + dur, a);
- assert_almost_eq!(b - dur, a);
+ assert_almost_eq!(a - dur, b);
} If I understand correctly, the original test is wrong. |
Hm no I don't believe that's the purpose of the test (that's a different equality). I know though that the arm setup has really weird clocks and it's not quite right in qemu, so it's fine to ignore the test there. |
@alexcrichton if the original test is correct that means we assert Do you mean we should revert ef8c204 and just |
Ah sorry no I think I misread and I believe you're right in that this is the intended test! Let's see if this works... @bors: r+ |
📌 Commit ef8c204 has been approved by |
@bors rollup |
…-duration-should-panic, r=alexcrichton Properly detect overflow in Instance ± Duration. Fix rust-lang#44216. The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic. The reason rust-lang#44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second. Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
I suspect that this is the cause of the following failure in the rollup (on armhf-gnu): @bors r-
|
ef8c204
to
1ba090c
Compare
Looks like the actual problem is that |
ab93811
to
f4e6bcc
Compare
Avoid unchecked cast from `u64` to `i64`. Use `try_into()` for checked cast. (On Unix, cast to `time_t` instead of `i64`.)
f4e6bcc
to
83d14bd
Compare
@alexcrichton Actual failure cause is found. As stated before, let eighty_years = second * 60 * 60 * 24 * 365 * 80;
assert_almost_eq!(a - eighty_years + eighty_years, a);
assert_almost_eq!(a - (eighty_years * 10) + (eighty_years * 10), a); Previously the test passed because the computation is done at Currently I disabled these tests when @bors rollup- |
@bors: r+ Thanks for the investigation! We may want to investigate a platform-independent representation of |
📌 Commit 83d14bd has been approved by |
@alexcrichton Filed issue #44394 for platform-indepndent representation of |
Thanks! |
⌛ Testing commit 83d14bd with merge 9999dc617244b1af1ee4bb5680406d61e82f161c... |
💔 Test failed - status-travis |
Legit. On macOS an |
@bors: r+ |
📌 Commit c5e9ef6 has been approved by |
⌛ Testing commit c5e9ef6593de104004512102bf0dfb4372c04ae4 with merge 49097d101b6187947e489134dca7dc2c8f93c1f9... |
💔 Test failed - status-travis |
c5e9ef6
to
4962f9d
Compare
@alexcrichton Fixed build failure. Sorry the import statement was wrong 😓. |
@bors: r+ |
📌 Commit 4962f9d has been approved by |
…hould-panic, r=alexcrichton Properly detect overflow in Instance ± Duration. Fix #44216. Fix #42622 The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic. The reason #44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second. Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
☀️ Test successful - status-appveyor, status-travis |
Fix #44216.
Fix #42622
The computation
Instant::now() + Duration::from_secs(u64::max_value())
now panics. The callreceiver.recv_timeout(Duration::from_secs(u64::max_value()))
, which involves such time addition, will also panic.The reason #44216 arises is because of an unchecked cast from
u64
toi64
, making the duration equivalent to -1 second.Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an
i64
, yet this is rejected because (2⁶³) overflows thei64
.