Subject: Re: [PATCH 4/7] xdiff: make fields of xrecord_t Rust friendly

From: "brian m. carlson" <[email-masked]>
Date: Thu, 17 Jul 2025 23:13:14 +0000

On 2025-07-17 at 22:46:56, Taylor Blau wrote:
> On Thu, Jul 17, 2025 at 08:32:21PM +0000, Ezekiel Newren via GitGitGadget wrote:
> > From: Ezekiel Newren <[email-masked]>
> >
> > A few commits ago, we added definitions for Rust primitive types,
> > to facilitate interoperability between C and Rust. Switch a
> > few variables to use these types. Which, for now, will
> > require adding some casts.
> 
> Hmm, interesting. I am not super familiar with how people typically
> handle interoperability between C and Rust, but having to change types
> on the C side to make it work with Rust is a bit surprising to me.
> 
> I would have expected that the Rust side would have declared its types
> using libc::c_int, libc::size_t, and so on. I think I have a vague
> preference towards putting the burden of casting on the Rust side, but,
> again, I am not super familiar with how transitions like these are
> typically approached.

Rust normally handles byte strings as slices or vectors of u8 (that is,
C's uint8_t).  C handles them as char, which may or may not be unsigned,
as we all know, which leads to some "entertaining" problems from time to
time.

Also, in general, Rust doesn't offer generic system-specific types, such
as `long`, except for C FFI.  This is actually a strong benefit, since
it means we're not inclined to write `unsigned long` and then wonder why
things are broken on Windows: instead, we write either `usize` (the
equivalent of `size_t`) or `u64` (for things like file sizes).  This is
much more ingrained than it is in Go, which has a tendency to use `int`
(Rust's `isize`) a lot and much less often specific types.

If we're going to move this code entirely into Rust, then it makes sense
to cast temporarily, and I'm fine doing that in C, since it's C that has
the weird system-dependent behaviour (arbitrary decisions on the
signedness of char).  That actually allows us to have more confidence in
the safety and maintainability of the Rust code since it is less system
dependent and leave the suspect pieces in C.  It may also, interestingly
enough, also allow us to easily get rid of the weird 2 GB limit on diffs
due to the unpleasant dependency on `int` in the xdiff code, which I
would absolutely love to see.

However, I'm not dead set against casting in Rust if that's what
everyone else wants instead.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA