August 13, 2026
Unsafe at Any Speed?
I want extern "fil-C"
Rust wants old C code on a safety leash, and the comments are already fighting
TLDR: The article proposes a new bridge that would let Rust use old C code more safely, making legacy code slower but less dangerous and giving teams a reason to rewrite the important parts later. Commenters loved the goal but instantly argued over whether this reinvents tools that already exist or finally fixes a long-standing mess.
A spicy idea just dropped: what if Rust, the programming language famous for trying to prevent memory disasters before a program even runs, could talk to old C libraries through a safer middleman instead of the usual "good luck out there" approach? That’s the pitch behind extern "fil-C": keep dusty old code, but force it to run with extra checks so bugs crash loudly instead of turning into security nightmares. In plain English, the dream is to make old code the safe-but-slower compatibility option, while rewritten Rust becomes the fast lane.
And oh, the comments immediately turned into a mini food fight. One camp was basically: wait, why make this hard on purpose? User andai zeroed in on the biggest eyebrow-raiser: Fil-C is intentionally not plug-and-play with normal C, and they questioned why that wall should stop Rust too. Another crowd rolled in with receipts, pointing to alternatives already used in the real world, like Mozilla’s RLBox, with pornel essentially saying, "guys, there is already a practical way to keep unsafe old libraries from trashing everything." Then came the classic internet cross-examination: why not just use Clang’s bounds safety mode?
Still, supporters were hyped. The most cheerleader-energy comment came from QuaternionsBhop, who loved the idea that developers might not need Rust’s dreaded unsafe marker just to call older code. That turned the whole debate into a deliciously nerdy culture war: should the future be a brand-new safety wall, a more compatible compromise, or just a better version of tools we already have? Underneath all the jargon, the vibe was simple: everyone wants safer old software — they just can’t agree on whose magic trick should win.
Key Points
- •The article proposes a Rust FFI that targets the Fil-C ABI instead of ordinary C to improve memory safety when using legacy C and C++ code.
- •Fil-C recompiles C and C++ with capabilities, runtime checks, and a concurrent garbage collector so memory-safety violations panic rather than become exploits.
- •The proposed first version would support a narrow interface including scalar values, copied strings and slices, and opaque handles, with safe Rust wrappers and no escape hatch to ordinary unsafe C.
- •Because Fil-C is intentionally not ABI-compatible with standard C, building the bridge would require Rust, Fil-C, or generated stubs to exchange values without weakening Fil-C’s guarantees.
- •The article cites filnix and Zig’s proposed `fil` ABI as existing ecosystem efforts that could help support a cross-language, memory-safe interoperability model.