Skip to content
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

linux: Add open_how and related flags #2477

Merged
merged 1 commit into from Nov 9, 2021
Merged

linux: Add open_how and related flags #2477

merged 1 commit into from Nov 9, 2021

Conversation

Fanael
Copy link
Contributor

@Fanael Fanael commented Oct 24, 2021

This makes openat2 usable.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

Please see the contribution instructions for more information.

@Fanael
Copy link
Contributor Author

Fanael commented Oct 29, 2021

NB: open_how should probably be non-exhaustive, because future kernel versions may add new members to the structure, to quote the man page:

Any future extensions to openat2() will be implemented as new fields appended to the above structure, with a zero value in a new field resulting in the kernel behaving as though that extension field was not present. Therefore, the caller must zero-fill this structure on initialization.

but #[non_exhaustive] is not supported by the MSRV. What's the best way of dealing with that scenario using what we can rely on?

@JohnTitor
Copy link
Member

NB: open_how should probably be non-exhaustive, because future kernel versions may add new members to the structure, to quote the man page:

Any future extensions to openat2() will be implemented as new fields appended to the above structure, with a zero value in a new field resulting in the kernel behaving as though that extension field was not present. Therefore, the caller must zero-fill this structure on initialization.

but #[non_exhaustive] is not supported by the MSRV. What's the best way of dealing with that scenario using what we can rely on?

We have a workaround to support a newer feature, see build.rs:

libc/build.rs

Lines 47 to 50 in 90ebf43

// Rust >= 1.19 supports unions:
if rustc_minor_ver >= 19 || rustc_dep_of_std {
println!("cargo:rustc-cfg=libc_union");
}

@Fanael
Copy link
Contributor Author

Fanael commented Oct 31, 2021

Updated and worked around the CI build failure. I'm not sure how to make style check happy now though: it can't use the same s! block because it needs cfg_if!, unless we're fine with only marking it as non-exhaustive only when supported, in which case #[cfg_attr(…)] would be enough.

@JohnTitor
Copy link
Member

Uhm, I think we can have non_exhaustive.rs just like align.rs?

@Fanael
Copy link
Contributor Author

Fanael commented Nov 3, 2021

Updated.

@bors
Copy link
Contributor

bors commented Nov 4, 2021

☔ The latest upstream changes (presumably #2499) made this pull request unmergeable. Please resolve the merge conflicts.

@JohnTitor
Copy link
Member

Thanks! @bors r+

@bors
Copy link
Contributor

bors commented Nov 8, 2021

📌 Commit 93e85a3 has been approved by JohnTitor

@bors
Copy link
Contributor

bors commented Nov 8, 2021

⌛ Testing commit 93e85a3 with merge 84b3a7b...

@bors
Copy link
Contributor

bors commented Nov 9, 2021

☀️ Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing 84b3a7b to master...

@bors bors merged commit 84b3a7b into rust-lang:master Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants