Please add clarification for casting ``mode_t`` to ``c_uint`` here

[phi-gamma]

Regarding:

openat/src/dir.rs

Line 268 in e4660c1

mode as libc::c_uint);

The cast was added in 8a25eae
which concerns freebsd support without further explanation. According to
the freebsd docs though, the mode argument is supposed to be of type
mode_t as well:

https://www.freebsd.org/cgi/man.cgi?query=openat&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html

If I’m reading the libc source correctly:

src/unix/mod.rs:pub type c_uint = u32;
src/unix/bsd/freebsdlike/mod.rs:pub type mode_t = u16;
src/unix/linux_like/linux/mod.rs:pub type mode_t = u32;

this is a no-op on Linux but a cast of u16 to a u32 on Freebsd.

Does the build actually fail on Freebsd if the cast is omitted? If so, maybe
this should be highlighted by a cfg guard. I don’t have a Freebsd system
at my disposal so I cannot test this myself.

(Sorry for being nitpicky here. I’m currently subjecting the crate to a crev
review so I had to waste some extra attention to the unsafe blocks.)

[tailhook]

@myfreeweb can you comment on this issue? (as you're the contributor if the line)

[valpackett]

You're looking at the wrong thing in the libc crate… grep for openat :) the create is not guaranteed to match the actual systems, always check its definitions.

It's currently defined in the unix module with c_uint. Yeah, that doesn't sound right, you should report it to the libc issue tracker. (But I'm not looking forward to libc API breakage, maybe this is fine lol)

[phi-gamma]

It's currently defined in the unix module with c_uint.

libc::openat is vararg as specified by posix,
so the signature has no explicit type for mode. Posix gives the type of mode as:
“The oflag parameter and the optional fourth parameter correspond exactly to the
parameters of open”. So assuming posix, the cast to c_uint is unnecessary.

Could you check whether rustc complains on Freebsd when the cast is removed?

[valpackett]

oh, I was looking at flags.

And yes, rustc complains, twice for some reason even.

error[E0617]: can't pass `u16` to variadic function
   --> src/dir.rs:270:29
    |
270 | ...                   mode);
    |                       ^^^^ help: cast the value to `c_uint`: `mode as c_uint`

error[E0617]: can't pass `u16` to variadic function
   --> src/dir.rs:270:29
    |
270 | ...                   mode);
    |                       ^^^^ help: cast the value to `c_uint`: `mode as c_uint`

(also the build was broken by O_PATH, I'll send a PR fixing it)

[phi-gamma]

So it does use the mode_t definition I cited above. Interesting.

I still think the cast should be cfg-guarded for Freebsd or at least
annotated to avoid confusing random people like me ;)

[valpackett]

So it does use the mode_t definition

No, only the functions in this crate use mode_t, but rustc does not allow passing that (when it's 16-bit) to the variadic args.

https://doc.rust-lang.org/error-index.html#E0617

So this means that variadic args literally cannot be mode_t==uint16_t because that is not allowed by the ABI. Actually the source of libc reads it as int.

I guess the bug is actually in the FreeBSD manpage, I've sent a patch.

[valpackett]

As for the cfg guard, idk… assuming no platform would use a 64-bit value, always casting to 32-bit would catch all platforms that use 16-bit :)

[bsdimp]

https://reviews.freebsd.org/rS352795 has been committed upstream. It really is an int due to the varadic arg promotion rules. FreeBSD then interprets the passed value as a mode_t, though...

[phi-gamma]

So it does use the mode_t definition

No, only the functions in this crate use mode_t, but rustc does not allow passing that (when it's 16-bit) to the variadic args.

I mean libc on Freebsd uses that u16 typedef for mode_t. Obviously this
can’t work with varargs in Rust due to the lack of integer promotion, which
answers my question as to why the cast is necessary.

https://doc.rust-lang.org/error-index.html#E0617

So this means that variadic args literally cannot be mode_t==uint16_t because that is not allowed by the ABI. Actually the source of libc reads it as int.

I guess the bug is actually in the FreeBSD manpage, I've sent a patch.

Nice.

I guess the takeaway is that it’s hard to follow Posix to the letter
where integer promotion rules don’t apply.

As for the cfg guard, idk… assuming no platform would use a 64-bit value, always casting to 32-bit would catch all platforms that use 16-bit :)

True, just that casting from mode_t to another type to satisfy a
signature that at least commonly requires a mode_t is a bit odd.

[bsdimp]

I think the takeaway is that C is a quirky language, and POSIX is a child of C. Rust tries not to be quirky and type safe. The is a dark corner of C where things aren't type safe at all and where arcane rules about what actually happens matter and the difference between those arcane rules and Rust's calling conventions become important.

Also, to quibble on a point. The signature does NOT require mode_t. It is varadic: int open(const char *fn, int flags, ...). mode_t is nowhere to be seen in the prototype. It is later documented that when flags has the O_CREAT it set, then an additional arg of type mode_t is required. Since that's passed through ..., the reader is expected to know and understand the subtle rules here, as described in the C standard and various processor ABI documentation. When O_CREATE isn't set, any argument passed is ignored and the caller is under no obligation to pass anything. There exist ABIs where this difference matters and where the arg that could otherwise be passed in a register is forced to the stack...