HN Debrief

I want extern "fil-C"

  • Programming
  • Security
  • Developer Tools
  • Open Source

The post proposes a new Rust foreign function interface, `extern "fil-C"`, that would let Rust call libraries compiled with Fil-C instead of ordinary C. Fil-C is a C system that adds runtime metadata and checks to stop out-of-bounds and related memory errors with finer precision than tools like AddressSanitizer or Valgrind. The appeal is obvious. Rust could keep its compile-time guarantees for most code, then pay a runtime cost only when crossing into legacy C that has been recompiled under Fil-C.

If you want safer interop with legacy C today, treat `extern "fil-C"` as a research idea, not an integration plan. For production work, the practical options raised here were sandboxing approaches like RLBox or incremental hardening like Clang `-fbounds-safety`, depending on whether you need isolation or ABI compatibility.

Discussion mood

Interested but skeptical. People liked the goal of safer legacy C interop, but most thought the proposal hand-waved the core obstacle that Fil-C's ABI and pointer model are deliberately incompatible with normal C and Rust.

Key insights

  1. 01

    Interop is the hard problem

    A clean Rust bridge would need more than a compiler switch because Fil-C code expects extra call and allocation metadata at runtime. That makes the problem less about exposing another ABI string and more about designing a foreign function interface where both sides agree on pointer semantics, memory layout, and runtime obligations. The key pushback is that nobody has shown how to do that without weakening the safety model that makes Fil-C interesting in the first place.

    Do not assume a memory-safe C dialect becomes easy to adopt once it has an FFI surface. Ask first what runtime invariants cross the boundary and whether your host language can honor them without adopting the same runtime.

      Attribution:
    • ameliaquining #1
    • Georgelemental #1
    • sheepscreek #1
    • pizlonator #1
  2. 02

    RLBox solves a narrower production need

    RLBox was cited as a working answer when the goal is to call legacy C codecs without giving them unrestricted access to the caller's memory. That framing sharpens the tradeoff. Fil-C aims at precise runtime enforcement inside C itself, while RLBox accepts a narrower model and focuses on containing untrusted libraries in a way Mozilla already ships.

    If your immediate problem is embedding risky third-party C, evaluate RLBox before betting on whole-program memory-safe C retrofits. It gets you deployable isolation without requiring the C codebase and all its dependencies to adopt a new runtime.

      Attribution:
    • pornel #1
    • pizlonator #1
  3. 03

    Clang bounds safety is the incremental path

    Clang `-fbounds-safety` came up because it keeps ABI compatibility and can be adopted gradually, which is exactly what mixed-language codebases usually need. The catch is that commenters drew a hard line between bounds checking and Fil-C's broader pointer-capability model. You get an easier rollout, but you are explicitly buying less protection.

    For teams with large existing C interfaces, ABI-compatible hardening may be worth more than maximal safety on paper. Choose it when integration friction is the blocker, not when you need strong enforcement against pointer misuse.

      Attribution:
    • KateLawson #1
    • pizlonator #1
  4. 04

    Copying across the boundary breaks fast

    The obvious fallback is to copy Rust data into Fil-C-managed memory, attach the needed metadata, and copy results back. Commenters pointed out why this falls apart quickly. Once the Fil-C side can mutate data, retain pointers globally, or depend on aliasing across calls, the host side no longer knows when a copy is authoritative or even safe to reconcile. At that point the interface starts to look more like a sandbox boundary than normal FFI.

    If your proposed safety boundary relies on copying, test it against retained pointers, mutation after return, and aliasing before calling it practical. Those cases usually decide whether the design is a real interop layer or just a serialization boundary.

      Attribution:
    • Panzerschrek #1
    • tracnar #1
    • SkiFire13 #1

Against the grain

  1. 01

    Rust plus Fil-C could still reduce unsafe

    The optimistic case is not that Fil-C magically preserves every Rust guarantee, but that it could remove a large chunk of `unsafe` code now spent on plain C FFI. That would still be valuable even if the combined model cannot prevent every aliasing or mutability pitfall Rust tracks internally. The attraction is operational. Replace today's wide-open C boundary with one that at least enforces runtime memory checks.

    If most of your `unsafe` exists to talk to C, keep an eye on tools that can narrow that trust boundary even imperfectly. Reducing the amount of handwritten unchecked interop code can pay off before you reach an ideal model.

      Attribution:
    • QuaternionsBhop #1
    • aw1621107 #1
  2. 02

    Fil-C's marketing claims are doing damage

    A harsher criticism was that the proposal inherits Fil-C's own framing about what counts as memory safety, and that framing is contested. The complaint is not mainly technical. It is that Fil-C presents itself as uniquely safe while discounting Rust or Zig whenever they expose escape hatches, despite having its own unsafe mechanisms and runtime assumptions. That makes some readers see `extern "fil-C"` as lending legitimacy to an argument they think is more branding than engineering.

    Separate the technical mechanism from the project's rhetoric before you adopt its terminology in your roadmap. Definitions that are useful in a research talk can still create confusion and resistance inside a real engineering organization.

      Attribution:
    • Wleddzig #1
    • ModernMech #1
    • mirashii #1 #2

In plain english

-fbounds-safety ↩
A Clang compiler feature that adds bounds-related safety checks while aiming to remain compatible with existing C ABIs.
ABI ↩
Application Binary Interface, the low-level calling convention and data representation rules used when compiled code interacts at runtime.
clang ↩
A compiler front end from the LLVM project, commonly used for C, C++, and Objective-C.
FFI ↩
Foreign Function Interface, a mechanism for calling code written in another programming language such as C.
Fil-C ↩
A modified C system that adds runtime metadata and checks to catch memory errors with stricter pointer tracking than normal C.
RLBox ↩
A sandboxing framework for safely calling risky native libraries from a host program by restricting how data crosses the boundary.
Valgrind ↩
A runtime instrumentation tool used to detect memory errors and leaks in native programs.

Reference links

Safer C interop and containment

  • RLBox
    Presented as a production-tested way to call legacy C libraries while limiting their access to the caller's memory.
  • Clang Bounds Safety overview
    Raised as an ABI-compatible and incrementally adoptable alternative to Fil-C-style interop.

Fil-C background and definitions

  • Fil-C runtime
    Linked to explain why Fil-C is not ABI compatible with normal C and what runtime support it expects.
  • Fil-C Invisicaps
    Used to point readers to Fil-C's own definition of memory safety and pointer model.

Alternative runtime safety approaches

Debates over Fil-C claims