-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Use 64-bit time on 32-bit linux-gnu #96657
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
(rust-highfive has picked a reviewer for you, use r? to override) |
(I fear the CI fallout of changing |
Looks reasonable to me. Let's give it a shot. @bors r+ |
📌 Commit 044becdef8d853dc29161611b538ef3c765d3dec has been approved by |
☔ The latest upstream changes (presumably #96510) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased. @bors r=joshtriplett rollup=iffy |
📌 Commit fec4818 has been approved by |
⌛ Testing commit fec4818 with merge 4fc439f674a020d2196357d7f38d2fef75fb0a70... |
This comment was marked as resolved.
This comment was marked as resolved.
I was missing |
This comment was marked as resolved.
This comment was marked as resolved.
@bors r+ rollup=iffy |
📌 Commit f967518 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (24a0eec): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
it seems to me that it breaks the build on OpenBSD:
any idea on how to properly correct it ? |
ok, the futex code for openbsd hasn't been updated. I will look at it |
rustup Adjusts for rust-lang/rust#96657. For now we use the fallback path in libstd.
…iper openbsd: convert futex timeout managment to Timespec usage unbreak openbsd build after rust-lang#96657 r? cuviper please note I made `Timespec::zero()` public to be able to use it. OpenBSD is using relative timeout for `futex(2)` and I don't find simple way to use `Timespec` this way.
The standard library suffered the Year 2038 problem in two main places on targets with 32-bit
time_t
:In
std::time::SystemTime
, we stored atimespec
that hastime_t
seconds. This is now changed to directly store 64-bit seconds and nanoseconds, and on 32-bit linux-gnu we try to use__clock_gettime64
(glibc 2.34+) to get the larger timestamp.In
std::fs::Metadata
, we store astat64
, which has 64-bitoff_t
but still 32-bittime_t
, and unfortunately that is baked in the API by the (deprecated)MetadataExt::as_raw_stat()
. However, we can usestatx
for 64-bitstatx_timestamp
to store in addition to thestat64
, as we already do to support creation time, and the rest of theMetadataExt
methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support, but that's not something Rust can change.There remain a few places that need
timespec
for system call timeouts -- I leave that to future work.