A Note on Fil-C

Original Article ↗ Hacker News Discussion ↗

Access and hosting issues

  • Several commenters hit 403 or geo-block pages unless visiting the Dreamwidth root with JS and third‑party scripts enabled.
  • Others share an Internet Archive link to work around regional restrictions.

Motivation and promise of Fil‑C

  • Strong enthusiasm for a path to memory safety for existing C/C++ without rewrites.
  • Seen as complementary to Rust: Rust for new code, Fil‑C for the vast body of legacy C that will never be rewritten.
  • Some argue this is pragmatically “obvious”: safer C is more realistic than rewriting all infrastructure.

Performance, GC, and InvisiCaps

  • Fil‑C’s current slowdown is attributed mainly to its capability scheme (InvisiCaps) and ABI, not GC.
  • The author lists major optimization avenues: a redesigned capability layout (saving two branches per pointer load), a custom object format and loader, a smarter abstract interpreter (e.g., octagon domain), more intrinsics, and a better calling convention.
  • One user notes negligible slowdown on an I/O‑bound daemon (udevd); others worry cumulative overhead across more components.
  • GC itself is described as highly concurrent and possibly faster than manual schemes in practice; removing it might even slow Fil‑C.

Runtime behavior and testing vs production

  • Fil‑C turns memory bugs (use‑after‑free, bounds, pointer–int confusion) into early panics; this makes latent C bugs visible but also causes crashes on paths that previously “worked by accident.”
  • Debate over using Fil‑C as a sanitizer or fuzzing target: some suggest it mainly fits development/testing, with lighter hardening in production.
  • Concerns raised that devs might stop calling free; responses clarify free still matters for catching UAF and compatibility.

Comparison to other safety tools and languages

  • Versus -fbounds-safety: Fil‑C aims at comprehensive memory safety without code changes; -fbounds-safety handles only bounds and needs annotations/changes.
  • Long discussion contrasts C/Fil‑C, Rust, Swift, Nim, Go, Java, C#, Python: tradeoffs among safety, performance, GC, verbosity, and ergonomics.
  • Some see memory‑safety focus as overhyped; others point to ongoing Linux compromises as evidence “good enough” C is not actually good enough.

History and enabling ideas

  • The author describes thinking about the problem since 2004, only recently finding a design (InvisiCaps) that offers “fanatical” C compatibility with tolerable performance.
  • Commenters link this to the modern C provenance model and abundant 64‑bit address space making such schemes practical, plus prior GCC bounds‑checking work.

C reliability, crashes, and Rust culture

  • Disagreement over claims that “almost all programs have paths that crash”; some cite mature C servers that rarely crash for users, others stress hidden exploitable bugs.
  • Error‑handling philosophy (“let it crash” with good diagnostics vs user‑friendly messages) is debated.
  • A long subthread criticizes Rust’s borrow checker and “fearless concurrency” marketing as overly restrictive; others counter that Rust’s constraints are explicit, well‑documented, and widely workable in production, with unsafe available for truly low‑level cases.