Target Audience for Review: Senior Systems Engineers, Compiler Architects, and Security Researchers specializing in memory safety and ABI design.

Abstract:

This material introduces Fil-C, a memory-safe implementation of C and C++ prioritizing "fanatical compatibility" with existing codebases. Fil-C achieves full memory safety without relying on unsafe escape clauses through a novel dynamic capability system known as "InvisiCaps" and a custom concurrent garbage collector, "FUGC" (Fil's Unbelievable Garbage Collector). InvisiCaps dynamically check all pointer operations against bounds and permissions while maintaining the standard 64-bit pointer size illusion. FUGC, a parallel, accurate, on-the-fly collector, ensures deterministic trapping of use-after-free (UAF) errors by disabling freed pointers. The ecosystem is validated by successfully porting the Qt Base framework, though this required addressing specific platform dependencies and LLVM intrinsic handling, demonstrating Fil-C’s efficacy in diagnosing and trapping memory safety violations in large, real-world C++ applications.

Fil-C: Technical Summary and Implementation Details

• Core Mandate (What is Fil-C?): Fil-C is a memory-safe implementation of C and C++ that compiles and runs highly complex legacy software (e.g., CPython, OpenSSH, GNU Emacs) with zero or minimal source code modification. All memory safety errors are converted into runtime panics.

• Mechanism 1: InvisiCaps (Invisible Capabilities):

  • Goal: Achieves complete pointer safety by dynamically tracking what memory object a pointer is allowed to access, prohibiting out-of-bounds access, UAF, and writes to read-only data.
  • Evolution: InvisiCaps are the latest iteration, succeeding PLUT (256-bit, non-thread-safe), SideCaps (256-bit, extremely slow), and MonoCaps (128-bit, 10x overhead).
  • Key Advantage: InvisiCaps allow pointers to remain 64-bit on 64-bit systems, significantly aiding compatibility and reducing performance overhead to about 4x in worst-case scenarios.
  • Pointer Structure: A "flight pointer" (local variable) consists of a trusted lower bound, an untrusted integer value (intval), and an upper bound/auxiliary word. When a pointer is stored to the heap ("rest pointer"), its capability metadata (the lower bound) is stored "outside" the address space visible to the C program (in an auxiliary allocation), making the pointer "invisible" to corruption attempts.

• Mechanism 2: FUGC (Fil's Unbelievable Garbage Collector):

  • Type: A parallel, concurrent, on-the-fly, grey-stack, Dijkstra accurate, non-moving GC.
  • Concurrency: Marking and sweeping run on separate threads from the mutator threads (the user program), interacting primarily via non-blocking synchronization and "soft handshakes" (ragged safepoints).
  • Store Barrier: Uses a Dijkstra barrier, which marks newly pointed-to objects during the marking phase, eliminating the need for a load barrier (Grey-stack technique).
  • Deterministic UAF: The use of a GC allows the free() operation to deterministically and atomically disable all pointers to the freed memory. The capability pointer (lower) is repointed to a "free singleton object," guaranteeing a trap on subsequent access, even after the memory is reclaimed.

• ABI and Toolchain:

  • The compiler is based on Clang 20.1.8 and supports standard C/C++ build systems (make, CMake).
  • Fil-C utilizes an ABI different from conventional C implementations ("Yolo-C"). Installation requires setting up a new ABI slice (e.g., the pizfix prefix approach or a recompiled userland like /opt/fil).

• Fil-Qt Case Study (Compilation of Qt Base):

  • Platform Setup: The demonstration required running an x86_64 Fil-C distribution using FEX emulation on an ARM64 Ubuntu system (Apple Silicon Mac).
  • Compatibility Challenges: Building Qt Base necessitated patching the build system, including fixes for cpuid, tagged memory pointers, and an unhandled LLVM intrinsic for llvm.x86.avx2.maskload.d.256, resulting in a runtime panic when Qt's AVX2 drawing helpers were invoked.
  • Safety Confirmation: A sample C++ snippet intentionally causing a use-after-free error in a QVector was compiled and executed. Fil-C successfully trapped the violation, generating a panic message identifying the access to the freed object.

• Community Discourse on Language Trade-offs:

  • Value Proposition: Fil-C is highly valued for hardening existing large frameworks (like Qt) without costly rewrites in languages like Rust, Java, or C#.
  • Performance vs. Safety Model: Discussion highlights the fundamental difference between Fil-C's dynamic runtime checking (incurring a performance penalty) and Rust's compile-time safety guarantees (achieving performance but imposing high complexity via the borrow checker and required use of explicit memory constructs).
  • Complexity Debate: Some users argue Rust's cognitive load and orthogonal systems (e.g., Result, Option, traits) make it overly complex, whereas Fil-C offers a simpler methodology for achieving safety in legacy C/C++.