I want extern "fil-c" · Domen Kožar

Skip to content

Building tools for better developer environments at cachix.org, secretspec.dev, and devenv.sh.

GitHub ↗<br>Twitter ↗<br>Email ↗

Rust&rsquo;s C FFI gives us access to decades of useful software, but the bargain is<br>backwards.

We use Rust to prove memory safety at compile time. Then we cross an unsafe<br>boundary and trust the C library to respect a contract that neither language<br>can enforce. The legacy code remains the cheap path, while rewriting it is the<br>expensive one.

Fil-C offers a more interesting bargain. It recompiles C<br>and C++ with capabilities, runtime checks, and a concurrent garbage collector.<br>Memory-safety violations panic instead of becoming exploits. Existing software<br>often needs few or no source changes, but it pays for safety at runtime.

I want a Rust FFI that speaks the Fil-C ABI.

The first version could be deliberately narrow: scalar values, copied strings<br>and slices, and opaque handles. It would generate safe Rust wrappers, compile<br>the complete C dependency graph with Fil-C, and provide no escape hatch back to<br>ordinary unsafe C. Shared memory could come later, once the bridge can give<br>Fil-C a capability that Rust can reliably revoke.

This is not a new option for bindgen. Fil-C is<br>source-compatible with C but intentionally not ABI-compatible,<br>and ordinary Rust extern "C" speaks the ABI Fil-C calls Yolo-C. Building the<br>bridge means teaching Rust, Fil-C, or a pair of generated stubs how to exchange<br>values without losing Fil-C&rsquo;s guarantees. If it were easy, it would already<br>exist.

One important part of this stack is already taking shape. filnix<br>packages Fil-C as a Nix cross-compilation platform and has ports for more than<br>100 nixpkgs packages. Treating Fil-C as a platform means Nix rebuilds the<br>transitive dependency closure for the Fil-C ABI instead of accidentally<br>linking ordinary C into it. filnix is not the Rust bridge yet, but it provides<br>the reproducible toolchain, package universe, and test bed where one could be<br>built.

Zig is approaching the same problem from another direction. Andrew Kelley has<br>proposed an optional fil ABI<br>inspired by Fil-C. It would be an independent implementation in the Zig<br>compiler and standard library, intended to compile a Zig program and its entire<br>C and C++ dependency tree with runtime memory safety. That is remarkably close<br>to the world a Rust bridge would need to enter.

But the result would give us exactly the right incentives.

We could use Rust for compile-time safety and then pay a performance penalty<br>for using C.

Keep the legacy library and it remains memory-safe, but every pointer operation<br>is checked and its memory participates in garbage collection. Rewrite the hot<br>path in Rust and those checks become static, so the tax disappears. C becomes<br>the safe compatibility path rather than the permanent fast path.

&ldquo;100% safe&rdquo; here means memory-safe across the whole supported boundary, not<br>free of logic bugs, deadlocks, or bad APIs. That boundary is the hard part.<br>Fil-C currently requires<br>the whole program and its dependencies to use its ABI.<br>The project also treats interoperability with ordinary C as a non-goal. A Rust<br>bridge would have to preserve that whole-world guarantee rather than quietly<br>punching a Yolo-shaped hole through it.

I want extern "fil-c": Rust on the fast path, old C on the safe path, and a<br>performance reason to finish the migration.

I would also like to see cross-ecosystem collaboration instead of several<br>almost-compatible islands. Fil-C has the capability model and working runtime.<br>Rust has compile-time safety. Zig is exploring a Fil-C-inspired ABI. Nix and<br>filnix can rebuild and test complete dependency graphs. This problem deserves<br>the best minds from all four communities in the same room.

So here is the invitation: join us at OceanSprint<br>next year in Lanzarote and build it together. Mikael Brockman, who is building<br>filnix, has already accepted.

Who else is joining us?

View the discussion thread.