File-locking API uses incorrect fnctl constants on at least sparc64

[glaubitz]

As described in #49773 (comment), the file-locking API uses incorrect fnctl constants on sparc64.

Compare the glibc headers on sparc64:

https://github.molgen.mpg.de/git-mirror/glibc/blob/master/sysdeps/unix/sysv/linux/sparc/bits/fcntl.h#L53

and what's in the rust sources:

https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_data_structures/flock.rs.html#45

Would there be a mechanism to sync the constants directly with the glibc sources, i.e. "using the headers"?

@jrtc27 @karcherm @psumbera @michaelwoerister @alexcrichton

[jonas-schievink]

I guess the mechanism would be "use the libc crate"

[glaubitz]

@jonas-schievink Indeed, I forgot the most obvious solution.

The constants are there and usable: https://github.com/rust-lang/libc/blob/master/src/unix/notbsd/linux/other/b64/sparc64.rs

[glaubitz]

I assume the correct code would be:

            pub const F_RDLCK: libc::c_short = libc::F_RDLCK;
            pub const F_WRLCK: libc::c_short = libc::F_WRLCK;
            pub const F_UNLCK: libc::c_short = libc::F_UNLCK;
            pub const F_SETLK: libc::c_int = libc::F_SETLK;
            pub const F_SETLKW: libc::c_int = libc::F_SETLKW;

[karcherm]

Also don't forget https://github.com/rust-lang/libc/blob/master/src/unix/notbsd/linux/other/mod.rs containing struct flock. As rustc_data_structures is already using the libc crate in that block, I strongly recommend to avoid to redefine either the structure or the constants in flock.rs, at least for the linux case.

[karcherm]

This will break, because we lose the dummy field l_sysid, but I recommend to solve this a different way, like defining a make_flock function that adds l_sysid = 0 for the BSD case.

[michaelwoerister]

This will break, because we lose the dummy field l_sysid, but I recommend to solve this a different way, like defining a make_flock function that adds l_sysid = 0 for the BSD case.

Could this be fixed in the libc crate itself?

[jrtc27]

Note that mips32 (both o32 and n32; mips64 ie n64 is fine) is the odd-one-out in Linux and does have l_sysid: https://github.com/rust-lang/libc/blob/8565755356f23baf6b2df933ff734ce2f00c8d9b/src/unix/notbsd/linux/mips/mips32.rs#L254.

[michaelwoerister]

That sounds like it should already work.

[michaelwoerister]

The code in rustc_data_structures/flock.rs is very old, from when we couldn't use any external crates in the compiler itself. I agree that we should switch the implementation to just using libc.

[karcherm]

And actually, it does not matter at all for us, because in the FreeBSD documentation, it says

The l_pid and l_sysid
fields are only used with F_GETLK to return the process ID of the process
holding a blocking lock and the system ID of the system that owns that
process.

So this field is an output field used by an operation not used at all here. If it's not a syntax error to not specify it, we can just ignore its existence.

[michaelwoerister]

If it's not a syntax error to not specify it, we can just ignore its existence.

We can handle this via either #[cfg!(...)] or std::mem::zeroed(). It would be even better if the struct implemented Default but I don't think it does.

[alexcrichton]

Would there be a mechanism to sync the constants directly with the glibc sources, i.e. "using the headers"?

@michaelwoerister is spot on that these were added to rustc way before we could depend on libc and crates.io crates. The libc crate is the source of truth for these constants, and the libc-test crate in that repository is this sync with system headers