Find more generic ways to handle smartlist_t/Vec<T> between C and Rust
From #25368 (moved), we discussed having a possibly more generic and/or more rusty way to handle our smartlist_t
s in C (and whatever underlying types the smartlist contains). Right now we have a Stringlist
type in src/rust/smartlist/smartlist.rs
, which is a Rust representation of smartlist_t
using C types, and then we have a conversion between that and a Vec<String>
:
pub trait Smartlist<T> {
fn get_list(&self) -> Vec<T>;
}
#[repr(C)]
pub struct Stringlist {
pub list: *const *const c_char,
pub num_used: c_int,
pub capacity: c_int,
}
impl Smartlist<String> for Stringlist {
fn get_list(&self) -> Vec<String> {
// [...]
}
}
I have not thought about this nearly as much as komlo has, but maybe one way to do it is to have direct conversion between a smartlist_t
and a Vec<T>
, where T
is probably an opaque pointer to whatever type in C, or T
is only allowed to be a String
which we've copied from a non-NULL char*
(e.g. impl From<Stringlist> for Vec<String>
, or something, and then keep Stringlist
private since internally it's a bunch of C types that we don't want propagating into our more Rusty code).
Another idea might be to only handle Vec<T>
-like things in Rust (if/when we move to the Rust-is-required phase), since we already have a nice datatype there, and then provide safe interfaces for C code to do all the things with/to the vectors that it currently does. (This sounds easier and more maintainable to me.)
We should probably brainstorm other ideas of how we're going to do this generically moving forward, because our C code uses smartlists everywhere.