Subject: Re: [PATCH v3 06/15] ivec: create a vector type that is interoperable between C and Rust

From: Ben Knoble <[email-masked]>
Date: Sun, 24 Aug 2025 09:31:22 -0400

> Le 22 août 2025 à 23:56, Ezekiel Newren via GitGitGadget <[email-masked]> a écrit :
> 
> From: Ezekiel Newren <[email-masked]>
> 
> Trying to use Rust's Vec in C, or git's ALLOC_GROW() macros (via
> wrapper functions) in Rust is painful because:
> 
>  * C doing vector things the Rust way would require wrapper functions,
>    and Rust doing vector things the C way would require wrapper
>    functions, so ivec was created to ensure a consistent contract
>    between the 2 languages for how to manipulate a vector.
>  * Currently, Rust defines its own 'Vec' type that is generic, but its
>    memory allocator and struct layout weren't designed for
>    interoperability with C (or any language for that matter), meaning
>    that the C side cannot push to or expand a 'Vec' without defining
>    wrapper functions in Rust that C can call. Without special care,
>    the two languages might use different allocators (malloc/free on
>    the C side, and possibly something else in Rust), which would make
>    it difficult for a function in one language to free elements
>    allocated by a call from a function in the other language.
>  * Similarly, git defines ALLOC_GROW() and related macros in
>    git-compat-util.h. While we could add functions allowing Rust to
>    invoke something similar to those macros, passing three variables
>    (pointer, length, allocated_size) instead of a single variable
>    (vector) across the language boundary requires more cognitive
>    overhead for readers to keep track of and makes it easier to make
>    mistakes. Further, for low-level components that we want to
>    eventually convert to pure Rust, such triplets would feel very out
>    of place.

I’m mildly surprised Vec isn’t a good fit: isn’t it a pointer, length, capacity triple? But it sounds like the main issue is allocator interop… which I would also have thought was supported? At least the current version is documented as being generic against an Allocator, too.

> 
> To address these issue, introduce a new type, ivec -- short for
> interoperable vector. (We refer to it as 'ivec' generally, though on
> the Rust side the struct is called IVec to match Rust style.)  This new
> type is specifically designed for FFI purposes, so that both languages
> handle the vector in the same way, though it could be used on either
> side independently. This type is designed such that it can easily be
> replaced by a standard Rust 'Vec' once interoperability is no longer a
> concern.

Am I reading the patch correctly that the ivec implementation is primarily C? I’m not familiar with too many FFI projects in Rust, but I might have hoped we could write parts in Rust to gain any benefits from that, too. Is that a fool’s errand I’m thinking of?