[tor-bugs] #25504 [Core Tor/Tor]: Find more generic ways to handle smartlist_t/Vec<T> between C and Rust

[Tor Bug Tracker & Wiki]

#25504: Find more generic ways to handle smartlist_t/Vec<T> between C and Rust
------------------------------+----------------------------------
     Reporter:  isis          |      Owner:  (none)
         Type:  enhancement   |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: 0.3.5.x-final
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:  rust, datatypes, ffi
Actual Points:                |  Parent ID:
       Points:  3             |   Reviewer:
      Sponsor:  Sponsor8-can  |
------------------------------+----------------------------------
 From #25368, 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>`:

 {{{#!rust
 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25504>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online