Where stop the ffi binding rustification?

help
1

Hello,

When I write a binding for a C library. First, I write a sys-crate with bindgen and, seconds, I write a safe crate with a better API. But where stop the rustification of the API?

For some topics, it’s easy : no unsafe function, no C types. But for method names, should I remove get_ prefix (as recommands in Rust API Guidelines)? If a clone method exist, should I replace it by a Clone implementation?

2 Likes
2

Don't change/Rustify bindings in the sys crate. Don't add any Rust code in the sys crate (apart from minimum to replace macros). More on sys best practices.

In a separate Rust wrapper crate keep adding Rust code until it no longer feels like C :slight_smile:

Wrapping C cloning calls in Rust clone is fine for high level wrappers, but be careful about error conditions - Clone trait can't fail.

5 Likes
3

That's a really good resource on sys crates.

If I have C/C++ code that I don't intend to use outside of a Rust crate, then I go with a simpler setup. Intsead of having a separate sys crate, I just include the FFI bindings in a module.

mod ffi {
    #[allow(non_snake_case)]
    include!(concat!(env!("OUT_DIR"), "/bindings.rs"));
}