Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helpers for calling FFI functions with "compatible types" #892

Open
alexcrichton opened this issue Feb 21, 2015 · 3 comments
Open

Helpers for calling FFI functions with "compatible types" #892

alexcrichton opened this issue Feb 21, 2015 · 3 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@alexcrichton
Copy link
Member

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(0 as *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.

@alexcrichton
Copy link
Member Author

cc @aturon

@blaenk
Copy link
Contributor

blaenk commented Feb 22, 2015

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.

@nagisa
Copy link
Member

nagisa commented Apr 1, 2015

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.

@petrochenkov petrochenkov added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Jan 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

4 participants