Implement ReprC for re-exported types

[liamdiprose]

I'm generating C bindings for a Rust crate that uses repr(C) types from it's dependencies.

Can safer_ffi generate bindings for these types?

Currently, the only way I can solve this is by writing an identical struct with #[derive_ReprC] and conversion functions for each type.

For example, how would you bind a function that returns this type?

[danielhenrymantilla]

Sadly the way trait impls work make it so you cannot implement ReprC for it, and I cannot realistically do it myself, unless I anticipated this and depended on that crate specifically. This is the "{De,}Serialize problem"; only, serde is popular enough to let library authors think of this, whereas other crates not necessarily.

So what you're doing is currently the only direct workaround on your end.

That being said, you could try the same solution as for {De,}Serialize:

1. fork the crate; and use a patch directive to depend on your fork;
2. add the #[derive_ReprC] invocations;
   • ideally, feature-gated behind some safer-ffi feature: #[cfg_attr(feature = "safer-ffi", ::safer_ffi::derive_ReprC)]
3. Submit a PR upstream and hope they accept it.

---

Automating the "twin struct" approach

This could be achieved with an approach similar to that of pavex, but it would be a major feature of safer-ffi (having some cli companion app), which I would love to undertake at some point; I just don't have the time at the moment to realistically achieve this below a 6-month horizon, I'd say 😔

• Demo: https://jqplay.org/s/XvDK3JXJ1br

[liamdiprose]

Thank you for this reply and your work. I recently read about the {De,}Serialise problem in Serde's documentation. Autogenerating the twin struct is a smart idea, but I agree it sounds like a lot of effort. It's nice to know we aren't required to pay with worthless conversions.

I'm in contact with the upstream authors who are interested in my effort, so it's a good idea to try a PR - Thank you for including the feature-gated version.

All the best for your future plans; Rust is great but C ain't going anywhere!