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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jul 31, 2025, 14:20 UTC
Message-ID: <ad453eee-23cd-42fe-97bd-1ff0fc2f3edf@gmail.com>
In-Reply-To: <CAH=ZcbALsQqTrvNJ4ZKmVWc6PHtTA+8k8p6_D=x=BfMXxnayfA@mail.gmail.com>

On 28/07/2025 21:14, Ezekiel Newren wrote:

Show 24 quoted lines

> On Mon, Jul 28, 2025 at 1:52 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> 
> Ah, I misunderstood the scope of your question. I could not fit an
> example of why this design pattern made sense into this patch series,
> so I'll explain with an example here:
> 
> If C defines a struct like below then it's obvious how to translate
> that into rust for ffi purposes. It also makes it clear that this C
> struct is expressly for the purpose of C <-> Rust interoperability.
> struct some_struct {
>      u8* ptr;
>      usize length;
>      u64 counter;
> };
> 
> This is how that C struct needs to be defined in Rust so that it can
> interoperate with C, and making C use the Rust types reduces the
> chance of copy paste, and primitive type definition mismatch errors.
> #[repr(C)]
> pub struct some_struct {
>      ptr: *mut u8,
>      length: usize,
>      counter: u64,
> };

How is the pointer, length pair used in rust? Normally one would use a slice so do we have to construct a slice every time we want to use the data in this struct, or do we copy the data in this struct into to a an idiomatic struct with a slice member? If we end up copying there doesn't seem much point in changing all the types in the C struct as we can define a rust struct using *c_char, c_long etc. to interface with the C code and covert them to an appropriate rust type when we copy the data to the idiomatic version that is then used by the rust of the rust code. I can see the value of the typedefs for documenting C<->rust interop if the same struct is used by both but if we end up copying data on the rust side I'm not so sure.

Thanks

Phillip