Update use of libc::timespec to prepare for future libc version#1886
Update use of libc::timespec to prepare for future libc version#1886bors[bot] merged 1 commit intonix-rust:masterfrom
Conversation
wesleywiser
force-pushed
the
update_timespec_usage
branch
from
fc7e421 to
ed2c4bf
Compare
asomers
left a comment
asomers
left a comment
There was a problem hiding this comment.
You should rebase on master, which already has the Clippy fixes. Otherwise, this change looks good.
| libc::timespec { | ||
| tv_sec: 0, | ||
| tv_nsec: 0, | ||
| .. |
There was a problem hiding this comment.
What's the function of this line? Are you programming defensively, just in case freebsd, netbsd, dragonfly, or illumos grow some padding fields too?
There was a problem hiding this comment.
It's required once Rust starts targeting musl 1.2 as i686-unknown-linux-musl will have a padding field:
$ cargo +e392e7b50913d5cb6e2c08d70cdeb72e56d289f9 build --target i686-unknown-linux-musl
Compiling libc v0.2.137 (https://github.com/wesleywiser/libc?branch=musl-1.2#3049e59a)
Compiling nix v0.25.0 (/tmp/nix)
error: pattern requires `..` due to inaccessible fields
--> src/sys/time.rs:116:25
|
116 | / libc::timespec {
117 | | tv_sec: 0,
118 | | tv_nsec: 0,
119 | | },
| |_________________________^
|
help: ignore the inaccessible and unused fields
|
118 | tv_nsec: 0, ..,
| ++++
There was a problem hiding this comment.
Oh, my bad. I saw that #[cfg()] block on line 100 and thought that it applied here.
There was a problem hiding this comment.
No problem, thanks for the quick reviews! 🙂
wesleywiser
force-pushed
the
update_timespec_usage
branch
from
ed2c4bf to
77f7eb4
Compare
In a future release of the `libc` crate, `libc::timespec` will contain private padding fields on `*-linux-musl` targets and so the struct will no longer be able to be created using the literal initialization syntax. Update places where `libc::timespec` is created to first zero initialize the value and then update the `tv_sec` and `tv_nsec` fields manually. Many of these places are in `const fn`s so a helper function `zero_init_timespec()` is introduced to help with this as `std::mem::MaybeUninit::zeroed()` is not a `const` function. Some matches on `libc::timespec` are also updated to include a trailing `..` pattern which works when `libc::timespec` has additional, private fields as well as when it does not (like for `x86_64-unknown-linux-gnu`).
wesleywiser
force-pushed
the
update_timespec_usage
branch
from
77f7eb4 to
006fc6f
Compare
|
@wesleywiser it looks like |
|
Sorry for the delay! I'll work on the backports tomorrow. |
2 participants
In a future release of the
libccrate,libc::timespecwill contain private padding fields on*-linux-musltargets and so the struct will no longer be able to be created using the literal initialization syntax.Update places where
libc::timespecis created to first zero initialize the value and then update thetv_secandtv_nsecfields manually. Many of these places are inconst fns so a helper functionzero_init_timespec()is introduced to help with this asstd::mem::MaybeUninit::zeroed()is not aconstfunction.Some matches on
libc::timespecare also updated to include a trailing..pattern which works whenlibc::timespechas additional, private fields as well as when it does not (like forx86_64-unknown-linux-gnu).See also rust-lang/libc#2088