Update use of libc::timespec to prepare for future libc version #528
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In a future release of the `libc` crate, `libc::timespec` will contains private padding fields on 32-bit `*-linux-musl` targets and so the struct will no longer be able to be created using the literal initializer syntax. The only uses in this crate of `libc::timespec` in this way were zero initializing the struct. Thus, these can be replaced by a call to `std::mem::zeroed()` which is compatible with both current versions of the `libc` crate as well as the future version which will contain those private padding fields.
|
This will be released as soon as I can fix CI. It's changed a fair amount since the last 0.1 release. |
|
Well, CI passes when using the latest stable, but fails with a linker error on MacOS on 1.21.0. I am able to successfully cross-compile it from Linux to MacOS on 1.21.0, so I'm releasing as-is. We'll find out soon enough if there are any issues 😄 |
|
Just FYI that seems to be a common issue with older Rust versions on newer macOS versions: Amanieu/parking_lot#363 (comment) Thanks so much for your help with this! |
|
Well, so be it. I figured if I could cross-compile it, then there was no true issue. Thanks for doing the legwork of the various patches. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a future release of the
libccrate,libc::timespecwill contains private padding fields on 32-bit*-linux-musltargets and so the struct will no longer be able to be created using the literal initializer syntax.The only uses in this crate of
libc::timespecin this way were zero initializing the struct. Thus, these can be replaced by a call tostd::mem::zeroed()which is compatible with both current versions of thelibccrate as well as the future version which will contain those private padding fields.I tested this locally both with a modified
libc/i686-unknown-linux-musltarget and with the currentlibc/i686-unknown-linux-musltarget. The code builds and all tests pass. The GH workflow required disabling adeny(warnings)for new warnings that are emitted since the last time the branch was built but it succeeded other than thetest-oldtasks which failed because of dependency resolution errors with thecfg-ifcrate.Related to rust-lang/libc#2088