Confused on how to create and destroy repr_c::Vec

[danielhenrymantilla]

Question from @TheButlah, at #109:

I used repr_c::Vec<T> in my FFI, but now I'm faced with a function that accepts a new repr_c::Vec as input. I don't see in the generated bindings any way to free or create a repr_c::Vec. Is that functionality unimplemented? Is there any documentation for this?

I know I can wrap drop() in a free_my_t() function, but that still doesn't address how to actually push items into a repr_c::Vec

[danielhenrymantilla]

So, safer-ffi currently "only" offers API where the types involved can pass the FFI boundary, either in an opaque manner, or through structs that expose fields (e.g., in the case of repr_c::Vec, it exposes the ptr, len and cap fields).

Anything beyond that, such as exposing an API to "work with a value of that type", has to be manually exported.

In other words, it's:

I know I can wrap drop() in a free_my_t() function

but for each and every desired API:

use ::safer_ffi::prelude::*;

#[derive_ReprC]
…
struct Item …

#[ffi_export]
fn vec_item_new ()
  -> repr_c::Vec<Item>
{
    c_vec![]
}

#[ffi_export]
fn vec_item_push (vec: &mut repr_c::Vec<Item>, item: Item)
{
    vec.with_rust_mut(|v| v.push(item));
}

#[ffi_export]
fn vec_item_free (vec: repr_c::Vec<Item>)
{
    drop(vec)
}

If this were to become too annoying / cumbersome in some cases, feel free to detail such situations, so that I can think of ways to help automate this (for instance, safer-ffi could offer macros to emit such code in the case of repr_c::Vec, or repr_c::String, or some other pervasive types).

[danielhenrymantilla]

Note that in certain cases, you could have the other API take a c_slice::Ref<'_, Item> rather than a repr_c::Vec<Item>, since a language such as C, and several other FFI languages such as C# with its fixed directive, can more easily generate pointers to contiguous regions of memory thence circumventing the need for the Rust side to expose the tools to do so 🙂

[danielhenrymantilla]

Finally, a quite advanced but dangerous / error-prone approach, if you wanted to do it quite "manually", would be to offer something like:

#[ffi_export]
fn vec_item_reserve (
    vec: &mut repr_c::Vec<Item>,
    capacity: usize,
)
{
    vec.with_rust_mut(|v| v.reserve(capacity));
}

and then directly use the ptr, len and cap fields as you initialize each element.

With it, from, say, C:

// say you have some vec, such as an empty one…
vec_item_t vec = vec_item_new();
// and you have 4 `item_t` which you want to add to that vec:
item_t item[4] = { … };

// you can then do:
vec_item_reserve(&vec, 4); // ensures `vec.cap ≥ vec.len + 4`.
for (size_t i = 0; i < 4; ++i) {
    vec.ptr[++vec.len] = item[i];
}

// And voilà, you can now feed your vec to the desired API
other_ffi_func(vec);

but to be honest I don't think that such snippet is really that much better than:

  // you can then do:
- vec_item_reserve(&vec, 4); // ensures `vec.cap ≥ vec.len + 4`.
  for (size_t i = 0; i < 4; ++i) {
-   vec.ptr[++vec.len] = item[i];
+   vec_item_push(&vec, item[i]);
}

[TheButlah]

Yep! I ended up basically writing my own macro that adds the various c functions for new drop and push, for each monomorphized type.

I'm not sure if this can be provided in a clean way as a built-in macro, but maybe! And I guess at the end of the day, people don't need to use that macro if they don't want to.

[fjarri]

for instance, safer-ffi could offer macros to emit such code in the case of repr_c::Vec.

Sorry to be piggybacking on this discussion, but that's something I wanted to ask too. Let's say I have some functions that take or return repr_c::Vec<A>. safer-ffi creates a Vec_A C struct for me. But where should I put the corresponding free declaration in Rust? Since Vec<A> is not declared anywhere explicitly, there's no obvious Rust module to put it in, and sometimes I might forget to do it.

I don't know what would be a good solution for that. Some options are:

• whenever a Vec_NNN struct is put in the C file, automatically create a free_Vec_NNN() function too. (too implicit?)
• wrap all occurrences of Vec in a newtype, so that the free function could be put near it (or even derived automatically via an attribute).

[danielhenrymantilla]

@fjarri yeah that sounds totally sensible; feel free to open a feature-request issue for this 🙂