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

[Patrick Steinhardt <ps@pks.im>]

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@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.

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