April 17, 2026
Three mallocs in a trench coat
A simplified model of Fil-C
C gets seatbelts: fans shout “Rust who?”, skeptics cry “fat pointers”
TLDR: Fil‑C shows how it rewrites C/C++ to add safety checks and metadata so old code can run with fewer memory bugs. The crowd’s split: some hail it as a “Rust without the rewrite,” others dismiss it as old “fat pointer” baggage, while one dev dropped a Bazel template to try it now
Fil‑C just dropped a simplified explainer showing how it turns risky C/C++ code into safer code by attaching a “shadow record” to every pointer and checking bounds before anything dangerous happens. Think of it like adding a babysitter to every memory pointer. The demo shows extra checks, special versions of malloc/free, and even a secret “invisible” sidecar for passing pointer safety info around. Techy? Sure. But the comments? Absolutely on fire.
On one side, the true believers: one fan calls Fil‑C “underrated” and basically says, why rewrite in Rust when you can just make C safe? Cue memes about “C with seatbelts” and “three mallocs in a trench coat” (because Fil‑C allocates three things under the hood). On the other, the buzzkill brigade: a skeptic calls it “yet another ‘fat pointer’ rerun,” worrying that the extra baggage breaks compatibility with normal code and slows everything down. Translation: great idea, but will it work with the real world—and at what cost?
Meanwhile, a builder swoops in with action: a ready‑to‑use Bazel template for hermetic (repeatable) builds, turning all this debate into something you can actually try. The vibe is Rust vs. C cage match, sprinkled with jokes, doubt, and a surprising amount of DIY energy. Popcorn, anyone?
Key Points
- •The simplified Fil-C model rewrites C/C++ source, while the production system rewrites LLVM IR via a compiler pass.
- •Each local pointer variable is paired with an AllocationRecord* that tracks visible bytes, invisible bytes, and length.
- •Pointer operations and function boundaries are rewritten so AllocationRecord* metadata is propagated alongside pointers.
- •filc_malloc performs three allocations (AllocationRecord, visible buffer, invisible buffer) and returns both pointer and metadata.
- •Dereferences include runtime bounds checks; for heap-stored pointers, invisible_bytes stores corresponding AllocationRecord* at aligned offsets.