Rust Needs extern "fil-c" to Make C Memory-Safe
I want extern "fil-C"
Rust's C FFI trades compile-time safety for access to legacy code, but Fil-C offers a better deal: recompile C/C++ with runtime checks and GC, making memory violations panic instead of exploit. The author proposes a Rust FFI for the Fil-C ABI, starting narrow, with no escape hatch to unsafe C. Filnix already packages Fil-C for Nix, and Zig is exploring a similar ABI. This could give Rust a safe compatibility path and a performance incentive to rewrite hot paths.
C becomes the safe compatibility path rather than the permanent fast path.
- andai
Why isn't fil-C ABI compatible with C?
Apparently this was done intentionally. The rationale given is that we don't want to allow non-safe C to be used in fil-C programs. Fair enough.
But why should we prevent fil-C programs to be used from Rust (or C, for that matter)?
I don't understand much about compilers, but I guess allowing one would also allow the other? i.e. it's not possible to make fil-C ABI compatible with C (so that it can be more easily called), while also not letting you use call C from it?
- pornel
There is a solution that Mozilla uses in prod for legacy C codecs:
It's not a replacement for Fil-C's role as a precise ASAN/Valgrind, but it works great if you want to call a C library without letting it freely spray caller's memory.
- Panzerschrek
Extern "fil-C" can't be compatible with Rust code or something similar. It requires a metadata block attached to each allocation. So, if a memory block has been allocated in Rust and a pointer to it is passed to a fil-C function, it can't access it correctly. The only way to allow such cross-langauge-and-abi calls is to compile Rust code itself like fil-C, which requires doubled memory consumption, expensive runtime checks and GC overhead.
- KateLawson
Any reason why you don't use clang's `-fbounds-safety`? It offers ABI compatibility and incremental adoption. The author of Fil-C worked on it also :-)
- QuaternionsBhop
This would also mean that you wouldn't need unsafe{} to call into the Fil-C ffi. The majority of unsafe{} in (non pure-rust) cargo dependencies is calling C ffi. Rust + Fil-C is a great match that fills a particular niche, I'd love to see it happen.