Re: [PATCH v3 06/15] ivec: create a vector type that is interoperable between C and Rust
Show 29 quoted lines
> Le 22 août 2025 à 23:56, Ezekiel Newren via GitGitGadget <gitgitgadget@gmail.com> a écrit :
>
> From: Ezekiel Newren <ezekielnewren@gmail.com>
>
> 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.
Show 9 quoted lines
>
> 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?
Ben Knoble <ben.knoble@gmail.com>