32 ms·
> Rewrite everything in Rust in one go? No? Just do what every good Rust programmer does today instead? If I have a C++ function like this: // If a == nul
by fluffything 6y ago
> Rewrite everything in Rust in one go?
No? Just do what every good Rust programmer does today instead?
If I have a C++ function like this:
// If a == nullptr the behavior is undefined
void foo(int* a);
the right way to provide a safe Rust API for it is to write:
mod ffi { extern "C" { fn foo(a: *mut c_int); } }
fn foo(a: *mut c_int) {
assert!(!a.is_null());
unsafe { ffi::foo(a) }
}
The crates being discussed here generate:
mod ffi { extern "C" { fn foo(a: *mut c_int); } }
fn foo(a: *mut c_int) {
unsafe { ffi::foo(a) }
}
instead (notice the missing assert), which is broken Rust code according to the Rust spec, because now `foo` will introduce undefined behavior into safe Rust every time its safely called with a null pointer. That is, doing this makes _all_ Rust safe code "unsafe", making the unsafe Rust keyword essentially meaningless, and negating any advantage that Rust has over C++ (memory safety, thread safety, lacks of segfaults, refactoring without introducing errors, etc.).
So you end up with 2 languages in your codebase, + a lot of glue boilerplate, for very little win.
If this is what you want, you are better off just sticking with C++ instead.
What Firefox, Servo, and any other good C++ project that cannot/does not want to review all C++ APIs does is to just write:
extern "C" { fn foo(a: *mut c_int); }
instead. That's less code, and it is correct code. When a programmer needs to call foo, they need to write "unsafe { foo(a) }", and that often leads to them actually checking "foo"'s API docs, and explaining why the call is safe (maybe the assert is not needed because a cannot be null. The burden of doing the work is on the caller.
Firefox and Servo heavily use `rust-bindgen`, which will automatically generate all these FFI wrappers with a correct ABIs for you. The main difference is that rust-bindgen does not attempt to falsely convey the idea that these APIs are safe to call.