On 2025-09-08 at 17:19:20, Ezekiel Newren wrote:

On Mon, Sep 8, 2025 at 8:13 AM Patrick Steinhardt [off-list ref] wrote:

quoted

+use std::os::raw::c_int;
+use std::os::raw::c_uchar;

I'd really rather avoid using C types in Rust, in favor of using Rust
types in C. I have written a commit that talks about why C should use
Rust primitive types and why Rust should avoid using C types, here:
https://lore.kernel.org/git/2a7d5b05c18d4a96f1905b7043d47c62d367cd2a.1757274320.git.gitgitgadget@gmail.com/ (local).
In my opinion, the type c_void is the only appropriate C type that
should be used on the Rust side, and should be used sparingly.

The std::os::raw::c_* directly inherits the problems of core::ffi,
which changes over time and seems to make a best guess at the correct
definition for a given platform/target. This probably isn't a problem
for all platforms that Rust supports currently, but can anyone say
that Rust got it right for all C compilers of all platforms/targets?

It also poses problems because if we use `c_ulong` and it's 64 bit, then
trying to do a `.into()` to convert it to a `u64` will cause the
compiler and linters to complain, even if it does compile successfully.
But on 32-bit systems or Windows, `c_ulong` will be `u32` and it will be
required to convert, since Rust doesn't allow automatic conversion
between types.  I have some personal Rust code which works with
`mode_t`, which on some Unix systems is 16 bits and on some systems is
32 bits and it has made me want to scream quite a bit.  It gets even
worse if the types differ in signedness.

It would be better to do `usize` and `u8` on the Rust side here and
`size_t` and `uint8_t` on the C side.  I think `unsigned char` and `u8`
is also fine, since we are not targeting systems where `unsigned char`
is not 8 bits in size.

I don't know how you plan to deal with the fact that Rust doesn't expose
`uintmax_t`, but I think that's 64-bit on all known systems (because
making it 128-bit would break ABI and nobody wants to bump libc's
SONAME), so you could try `u64` and `uint64_t` for the value instead.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA