-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Implement checked_add_duration for SystemTime #55527
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
0a87de2
to
3aced4c
Compare
I just noticed that I also need to make make |
3aced4c
to
dd605a1
Compare
I think the PR is ready for review/an automated all-platforms test run. Is there an easy way to just try to compile it on all platforms? |
687eac9
to
52ba35d
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
52ba35d
to
74d7fba
Compare
LGTM with the issue number changed! |
74d7fba
to
8e4711d
Compare
When will the full test suite (all platforms) be run? I expect some problems at first due to conditional compilation (which I can't test). |
@bors r+ It'll run now! No worries if it bounces a couple of times due to the platform specific stuff - it happens all the time. |
📌 Commit 8e4711d65612f61f57845738db90bccec59d9833 has been approved by |
@bors r- Failed in #55943 (comment) on wasm32. |
⌛ Testing commit 8231831 with merge dee94cd6869ed5b55506b11479dafa5f1ad523da... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Since SystemTime is opaque there is no way to check if the result of an addition will be in bounds. That makes the Add<Duration> trait completely unusable with untrusted data. This is a big problem because adding a Duration to UNIX_EPOCH is the standard way of constructing a SystemTime from a unix timestamp. This commit implements checked_add_duration(&self, &Duration) -> Option<SystemTime> for std::time::SystemTime and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many add_duration(&self, &Duration) -> SystemTime functions to avoid redundancy (they now unwrap the result of checked_add_duration). Some basic unit tests for the newly introduced function were added too.
8231831
to
f2106d0
Compare
Triage; @sfackler Hello, have you been able to get back to this PR? |
@bors r+ |
📌 Commit f2106d0 has been approved by |
Sorry, missed that you updated this - github doesn't notify on force pushes :( |
Implement checked_add_duration for SystemTime [Original discussion on the rust user forum](https://users.rust-lang.org/t/std-systemtime-misses-a-checked-add-function/21785) Since `SystemTime` is opaque there is no way to check if the result of an addition will be in bounds. That makes the `Add<Duration>` trait completely unusable with untrusted data. This is a big problem because adding a `Duration` to `UNIX_EPOCH` is the standard way of constructing a `SystemTime` from a unix timestamp. This PR implements `checked_add_duration(&self, &Duration) -> Option<SystemTime>` for `std::time::SystemTime` and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many `add_duration(&self, &Duration) -> SystemTime` functions to avoid redundancy (they now unwrap the result of `checked_add_duration`). Some basic unit tests for the newly introduced function were added too. I wasn't sure which stabilization attribute to add to the newly introduced function, so I just chose `#[stable(feature = "time_checked_add", since = "1.32.0")]` for now to make it compile. Please let me know how I should change it or if I violated any other conventions. P.S.: I could only test on Linux so far, so I don't necessarily expect it to compile for all platforms.
☀️ Test successful - status-appveyor, status-travis |
This PR acknowledges that |
Yeah, seems best to alter the tests to avoid pre-epoch times if those aren't universally supported. |
Original discussion on the rust user forum
Since
SystemTime
is opaque there is no way to check if the result of an addition will be in bounds. That makes theAdd<Duration>
trait completely unusable with untrusted data. This is a big problem because adding aDuration
toUNIX_EPOCH
is the standard way of constructing aSystemTime
from a unix timestamp.This PR implements
checked_add_duration(&self, &Duration) -> Option<SystemTime>
forstd::time::SystemTime
and as a prerequisite also for all platform specific time structs. This also led to the refactoring of manyadd_duration(&self, &Duration) -> SystemTime
functions to avoid redundancy (they now unwrap the result ofchecked_add_duration
).Some basic unit tests for the newly introduced function were added too.
I wasn't sure which stabilization attribute to add to the newly introduced function, so I just chose
#[stable(feature = "time_checked_add", since = "1.32.0")]
for now to make it compile. Please let me know how I should change it or if I violated any other conventions.P.S.: I could only test on Linux so far, so I don't necessarily expect it to compile for all platforms.