You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be awesome if the std::ffi module contained utilities which serves as common conversions from Rust types to C types in FFI functions. For example in git2-rs I have a macro which will call a function but convert each argument to it's "C equivalent" before doing so.
The conversion trait is pretty ad-hoc at the moment, but it encompasses a number of useful conversions such as:
&T => *const T
&mut T => *mut T
CString => *const c_char
Option<CString> => *const c_char (nullable)
Option<&T> => *const T (nullable)
bool => c_int
These sorts of conversions may not be appropriate for Rust at large, but the general idea is that types like Option<CString> are pretty painful to convert to a nullable pointer today:
let foo:Option<CString> = ...;let ptr = foo.as_ref().map(|s| s.as_ptr()).unwrap_or(0as*const_);
This issue is also motivated by rust-lang/rust#16035 because it would serve two purposes:
We could remove/deprecate as_ptr in favor of as_ref. This would break code such as the line above (because as_ptr would return a reference that would not be coerced to a raw pointer) but the old behavior could be opted into with this conversion trait.
The need to call as_ptr in the first place actually largely goes away as you can in theory pass the &CString to the C call directly (when using a macro like shown above).
More broadly this sort of helper or trait plays into the story of writing unsafe code in Rust (and improving the ergonomics thereof) and may have other considerations. I'm sure there are also quite a few variants of the trait I've got already floating around in other crates as well :). Regardless, it would be nice to have a standard method of converting to a "C compatible" representation and perhaps even a nice convenient macro.
The text was updated successfully, but these errors were encountered:
Yeah, I also wrote macros in my bindings to do these conversions and it was a pain. I didn't think to create a trait like you did, so my macros got ugly. I definitely think that would be useful.
This, or rather rust-lang/rust#16035 must be fixed by beta, which suggests this RFC has to be approved and implemented in less than 3 days that’re left.
It would be awesome if the
std::ffi
module contained utilities which serves as common conversions from Rust types to C types in FFI functions. For example in git2-rs I have a macro which will call a function but convert each argument to it's "C equivalent" before doing so.The conversion trait is pretty ad-hoc at the moment, but it encompasses a number of useful conversions such as:
&T
=>*const T
&mut T
=>*mut T
CString
=>*const c_char
Option<CString>
=>*const c_char
(nullable)Option<&T>
=>*const T
(nullable)bool
=>c_int
These sorts of conversions may not be appropriate for Rust at large, but the general idea is that types like
Option<CString>
are pretty painful to convert to a nullable pointer today:This issue is also motivated by rust-lang/rust#16035 because it would serve two purposes:
as_ptr
in favor ofas_ref
. This would break code such as the line above (becauseas_ptr
would return a reference that would not be coerced to a raw pointer) but the old behavior could be opted into with this conversion trait.as_ptr
in the first place actually largely goes away as you can in theory pass the&CString
to the C call directly (when using a macro like shown above).More broadly this sort of helper or trait plays into the story of writing unsafe code in Rust (and improving the ergonomics thereof) and may have other considerations. I'm sure there are also quite a few variants of the trait I've got already floating around in other crates as well :). Regardless, it would be nice to have a standard method of converting to a "C compatible" representation and perhaps even a nice convenient macro.
The text was updated successfully, but these errors were encountered: