How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
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?
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.
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.
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 :-)
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.
> [...] instead of accidentally linking ordinary C into it
Out of curiosity. If you really needed to, could a language speak both the C ABI and the Fil-C ABI? As I understand Fil-C itself can't do this without having Python-like FFI overhead, but maybe a different compiler implementation could?
Boundary just moves to the shim layer. Bridge code writes raw pointers into fil-C's world, corrupts memory same as before, just from a smaller attack surface. Fine if you audit that glue religiously, which nobody will at 3am during an incident.
Speaking both ABIs at once misses the point. The moment you let raw C pointers into Fil-C memory unchecked, you've reintroduced exactly the corruption class Fil-C exists to eliminate. FFI overhead isn't the cost, it's the boundary doing its job.
LLM-written post, but I think the core idea is okay. I would advocate for more opportunities for safety, even if some of the safety is runtime safety rather than "only" Rust's borrow checker.
Hm on first reading I was confused by the extern "fil-c" framing -- that seems to imply a bridge between C and Fil-C, which introduces some nasty language/runtime inter-op issues.
But I like this part
I want a Rust FFI that speaks the Fil-C ABI. ... We could use Rust for compile-time safety and then pay a performance penalty for using C.
Small nit: "slop" usually refers to AI-generated junk, not just prose that reads oddly. Fil-C is a real, well-documented project by Filip Pizlo. Might just be unfamiliar phrasing, not slop.
Saw this movie before with Cyclone back in 2002, fat pointers and bounds metadata, same ABI headaches. Every "safe C" project eventually hits the FFI wall. Fil-C's just the latest rerun, capability pointers instead of the CHERI hardware version.
https://fil-c.org/runtime
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?