On Mon, Sep 08, 2025 at 10:22:50PM +0000, brian m. carlson wrote: > On 2025-09-08 at 17:19:20, Ezekiel Newren wrote: > > On Mon, Sep 8, 2025 at 8:13 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > > +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@xxxxxxxxx/. > > 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. Fair. I think for now I'll add a preparatory patch to make the width of integers explicit in the C part. But if we agree on the approach picked by Ezekiel I think it does make sense to unify this towards Rust types eventually. Patrick
