Properly detect overflow in Instance ± Duration.

[kennytm]

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.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

@bors: r+

Looks great, thanks!

[bors]

📌 Commit abc11c3 has been approved by alexcrichton

[bors]

⌛ Testing commit abc11c3 with merge f2b7ddd...

[bors]

💔 Test failed - status-travis

[kennytm]

armhf-gnu failed, legit.

[01:13:00] failures:
[01:13:00] [01:13:00] ---- time::tests::system_time_math stdout ----
[01:13:00] thread 'time::tests::system_time_math' panicked at 'overflow when subtracting duration from time', /checkout/src/libcore/option.rs:839:4
[01:13:00] [01:13:00] [01:13:00] failures:
[01:13:00] time::tests::system_time_math
[01:13:00] [01:13:00] test result: FAILED. 801 passed; 1 failed; 1 ignored; 0 measured; 0 filtered out
[01:13:00] [01:13:00] �[m�[m�[31m�[1merror:�[m test failed, to rerun pass '--lib'

[kennytm]

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

[alexcrichton]

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.

[kennytm]

@alexcrichton if the original test is correct that means we assert a ≈ b + dur && a ≈ b - dur? That's only possible if dur ≈ 0, which won't be true especially when the SystemClock::now is "weird".

Do you mean we should revert ef8c204 and just #[cfg] out the test outside of x86?

[alexcrichton]

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+

[bors]

📌 Commit ef8c204 has been approved by alexcrichton

[Mark-Simulacrum]

@bors rollup

[Mark-Simulacrum]

I suspect that this is the cause of the following failure in the rollup (on armhf-gnu):

@bors r-

[01:11:59] thread 'time::tests::system_time_math' panicked at 'overflow when subtracting duration from time', /checkout/src/libcore/option.rs:839:4
[01:11:59] [01:11:59] [01:11:59] failures:
[01:11:59] time::tests::system_time_math
[01:11:59] [01:11:59] test result: FAILED. 807 passed; 1 failed; 1 ignored; 0 measured; 0 filtered out

[kennytm]

Looks like the actual problem is that time_t on armhf-gnu is 32-bit, so 80 years is too long.

[kennytm]

@alexcrichton Actual failure cause is found. As stated before, time_t on armhf-gnu is 32-bit, thus won't support a difference more than ~68 years (2³¹ seconds). The two tests below will always fail:

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 i64 and unchecked-cast to time_t as the final step. The a - (800 years) test should overflow.

Currently I disabled these tests when time_t is 32-bit. But would it make more sense we store the system time as i64 unconditionally instead of time_t?

---

@bors rollup-

[alexcrichton]

@bors: r+

Thanks for the investigation!

We may want to investigate a platform-independent representation of Duration and Instant in the future, yeah, but that's fine to happen in a separate PR.

[bors]

📌 Commit 83d14bd has been approved by alexcrichton

[kennytm]

@alexcrichton Filed issue #44394 for platform-indepndent representation of SystemTime. (Duration is already platform-independent. Instant have some tricky interaction on Windows which may be difficult to port.)

[alexcrichton]

Thanks!

[bors]

⌛ Testing commit 83d14bd with merge 9999dc617244b1af1ee4bb5680406d61e82f161c...

[bors]

💔 Test failed - status-travis

[kennytm]

Legit. On macOS an Instant is represented by 64-bit nanoseconds, so u64::MAX seconds will overflow and converting to an Instant. The panic message is "overflow converting duration to nanoseconds", which is different from Windows' "overflow when converting duration to intervals". Fixed by just checking for the word "overflow" in the error pattern.

[alexcrichton]

@bors: r+

[bors]

📌 Commit c5e9ef6 has been approved by alexcrichton

[bors]

⌛ Testing commit c5e9ef6593de104004512102bf0dfb4372c04ae4 with merge 49097d101b6187947e489134dca7dc2c8f93c1f9...

[bors]

💔 Test failed - status-travis

[kennytm]

@alexcrichton Fixed build failure. Sorry the import statement was wrong 😓.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 4962f9d has been approved by alexcrichton

[bors]

⌛ Testing commit 4962f9d with merge ca94c75...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ca94c75 to master...