Skip to content
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion src/unix/linux_like/linux/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -2129,7 +2129,8 @@ pub const _PC_ALLOC_SIZE_MIN: c_int = 18;
pub const _PC_SYMLINK_MAX: c_int = 19;
pub const _PC_2_SYMLINKS: c_int = 20;

pub const MS_NOUSER: c_ulong = 0xffffffff80000000;
// FIXME: should this be an int? The suffix is `U` not `UL`.
pub const MS_NOUSER: c_ulong = 1 << 31;
Comment on lines -2132 to +2133
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote the glibc patch. Sorry, I didn't expect breakage here.

Here is my rational from the commit message [1]:

Using gcc -Wshift-overflow=2 -Wsystem-headers to compile a file
including <sys/mount.h> will cause a warning since 1 << 31 is undefined
behavior on platforms where int is 32-bits.

Technically unsigned integers aren't allowed in C enum types, it is a GCC extension that is widely supported. We decided it was safe to use since the extension is already required for EPOLLONESHOT and EPOLLET [2].

Regarding the FIXME, I am not super familiar with Rust, but the mount function uses unsigned long for the flags argument. Until C23 enums could not have a type other than int, otherwise UL probably would have made more sense. Hopefully that helps you a bit in your decision.

[1] https://inbox.sourceware.org/libc-alpha/[email protected]/
[2] https://inbox.sourceware.org/libc-alpha/[email protected]/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your patch makes complete sense, I assume the intent was always to be 0x80000000 rather than the sign-extended 0xffffffff80000000. I just left that fixme as something to double check after the experimentation here; surprised you found this PR out of the blue, but thank you for saving me the work :)

I wrote the glibc patch. Sorry, I didn't expect breakage here.

Not at all a problem, there's nothing user-visible—just a test failure checking the equality of constants. Expected whenever the libraries we test against get updated.


pub const _SC_ARG_MAX: c_int = 0;
pub const _SC_CHILD_MAX: c_int = 1;
Expand Down
Loading