You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a TimeSpec from a std::time::Duration with more than libc::time_t seconds, the resulting value might be negative and will no longer preserve monotonicity with respect to the input duration. This happens to the integer casting in TimeSpec::from_duration.
I learned about this behavior through errors for negative timeouts from ppoll on Linux at runtime (serialport/serialport-rs#207). I did not expect this for the "porcellain" type Duration and the docs did not hint at it. And likely other users of the "porcellain" as well. When manually converting to the "plumbing" typetime_t I wold have looked deeper into the nitty gritty integer casts and cared for this case by saturating.
So shouldn't TimeSpec::from_duration preserve monotonicity? Isn't an inaccurate but still large TimeSpec less surprising?
The text was updated successfully, but these errors were encountered:
The problem is that a Unix Timespec can't represent times greater than i64::MAX seconds. Saturating the conversion would be bad, because then subtracting two TimeSpecs that were produced by TimeSpec::from_duration wouldn't be guaranteed to give the correct answer. Arguably, what Nix ought to do would be to provide TimeSpec::from_instant(i: std::time::Instant) instead of from_duration, because std::time::Instant actually uses a TimeSpec under the hood. And perhaps a TryFrom<Duration> impl, too.
The problem is that a Unix Timespec can't represent times greater than i64::MAX seconds. Saturating the conversion would be bad, because then subtracting two TimeSpecs that were produced by TimeSpec::from_duration wouldn't be guaranteed to give the correct answer.
This is a fair point against saturating.
And perhaps a TryFrom<Duration> impl, too.
What about transitioning towards this impl over some time? I could prepare PRs for adding TryFrom<Duration> and once this is released the successor for deprecating From<Duration> so that other young players could get safely around this.
What about transitioning towards this impl over some time? I could prepare PRs for adding TryFrom<Duration> and once this is released the successor for deprecating From<Duration> so that other young players could get safely around this.
When creating a
TimeSpec
from astd::time::Duration
with more thanlibc::time_t
seconds, the resulting value might be negative and will no longer preserve monotonicity with respect to the input duration. This happens to the integer casting inTimeSpec::from_duration
.See this example on Rust Playground.
I learned about this behavior through errors for negative timeouts from
ppoll
on Linux at runtime (serialport/serialport-rs#207). I did not expect this for the "porcellain" typeDuration
and the docs did not hint at it. And likely other users of the "porcellain" as well. When manually converting to the "plumbing" typetime_t
I wold have looked deeper into the nitty gritty integer casts and cared for this case by saturating.So shouldn't
TimeSpec::from_duration
preserve monotonicity? Isn't an inaccurate but still largeTimeSpec
less surprising?The text was updated successfully, but these errors were encountered: