> Le 22 août 2025 à 23:56, Ezekiel Newren via GitGitGadget <gitgitgadget@xxxxxxxxx> a écrit : > > From: Ezekiel Newren <ezekielnewren@xxxxxxxxx> > > 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?
