-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Properly detect overflow in Instance ± Duration. #44220
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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
.