Re: [PATCH RFC v3 5/8] rust: implement a test balloon via the "varint" subsystem

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 8, 2025, 22:22 UTC
Message-ID: <aL9XOj1sVmHGjDRn@fruit.crustytoothpaste.net>
In-Reply-To: <CAH=ZcbA_8JM1hdUAfFe3ho0ShuniguEpV1308S0nCkCHOCsmmg@mail.gmail.com>

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

Show 16 quoted lines

> On Mon, Sep 8, 2025 at 8:13 AM Patrick Steinhardt <ps@pks.im> 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@gmail.com/.
> 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