On Thu, Jul 17, 2025 at 11:13:14PM +0000, brian m. carlson wrote: > 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 <ezekielnewren@xxxxxxxxx> > > > > > > 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. Ahhh. Thanks for the patient explanation. That makes a lot of sense, and casting on the Rust side seems like the right approach for this spot. Thanks, Taylor
