Fil-C: A memory-safe C implementation

Original Article ↗ Hacker News Discussion ↗

Portability and implementation

  • Current implementation targets x86_64 Linux, but is built on LLVM and not fundamentally tied to x86, 64-bit, or a particular OS.
  • Author is intentionally limiting platforms to keep the test matrix manageable, but multiple commenters lobby for AArch64 next.
  • ARM MTE is discussed; Fil-C’s approach is described as deterministic vs. MTE’s probabilistic protection.

Motivation: legacy C and security

  • Many see something like Fil-C as essential to keep running vast existing C/C++ codebases safely without full rewrites.
  • Emphasis that the real audience is users of C programs (e.g., browsers, email clients) rather than C authors.
  • Some argue declining use of C, not compilation mode, is what will threaten this “intellectual heritage”; others counter that C remains pervasive.

Performance and trade-offs

  • Headline “4× slowdown” is criticized as misleading; that figure is presented as a worst-case upper end, not typical.
  • Discussion whether, at that cost, one might as well use GC’d languages like Go or C#, or Rust for safety + speed.
  • Counterargument: many contexts value security over raw performance (e.g., network-facing services, possibly military apps), and computers are fast enough that a moderate slowdown is acceptable.

Capabilities, InvisiCaps, and low-level code

  • Detailed exploration of how Fil-C’s capability-based pointers work: misaligned pointer loads trap; frames are GC-allocated; use-after-return is prevented by keeping frames alive if referenced.
  • Example shows classic “store stack buffer in global and use later” working safely due to GC-managed frames.
  • Integer-to-pointer casts are generally blocked to prevent capability forging, but “obviously reversible” laundering patterns and some const-dropping patterns are allowed.
  • Concerns that this disqualifies Fil-C for some kernel/MMIO tasks; proposed solutions include explicit unsafe intrinsics and linker-placed symbols.
  • Fil-C already supports mmap-based MMIO and has capability-preserving intrinsics for pointer tagging and tables.

Relation to other tooling and languages

  • Compared with previous efforts like Softbound+CETS, CCured, Firebloom, and clang’s -fbounds-safety.
  • Go and Rust raised as alternatives; replies stress you can’t trivially run arbitrary C/C++ in them, and wholesale rewrites are unrealistic.
  • Mention that a “safe C++” proposal has been abandoned, highlighting appetite for external solutions like Fil-C.

Ecosystem experiments (Nix/filnix)

  • Active work to integrate Fil-C into Nix as a full toolchain/ABI (…-linux-filc), enabling Fil-C builds of tmux, coreutils, Perl, Tcl, Lua, SQLite, etc.
  • Vision: NixOS or similar could selectively harden large swaths of userland (e.g., OpenSSHd, browsers, Flatpaks) with Fil-C builds.

Safety, debugging, and limitations

  • Some worry users may treat Fil-C as a bug-finder, then compile the same code with a normal compiler and assume equivalent safety.
  • Desire for diagnostics that flag UB-like constructs rather than just making them safe.
  • Debate over GC vs ARC vs ownership models: GC overhead vs memory footprint, and whether static analysis could remove many checks without annotations.
  • Overall sentiment: strong enthusiasm for the technical approach and its potential impact, tempered by questions about performance, low-level compatibility, and long-term positioning next to safer languages.