Fil-C: a memory-safe C/C++

[Tom Van Cutsem]

Hi friam,

I don't think I've seen anyone post this before:

Fil-C, a memory-safe C/C++: https://fil-c.org/

Fil-C achieves pointer safety using a capability system for pointers:

https://fil-c.org/invisicaps

What I find remarkable is that a good deal of C/C++ code seems to be portable to Fil-C as-is. This includes codebases like OpenSSH, CPython, or even the entire Linux userland code.

Dan Bernstein seems to approve: he used Fil-C to recompile a bunch of Debian packages without much hassle: https://cr.yp.to/2025/fil-c.html

Fun fact: Fil-C's author, Filip Pizlo, previously led the Javascript VM team at Apple.

KR,

Tom

[Tony Arcieri]

On Tue, Nov 11, 2025 at 1:08 PM Tom Van Cutsem <tomv...@gmail.com> wrote:

Fil-C achieves pointer safety using a capability system for pointers:

https://fil-c.org/invisicaps

A big part of how it works is a garbage collector which can track ownership of data based on pointers, so pointers cannot accidentally be used to access data they weren't intended to point to:

https://fil-c.org/fugc 

--

Tony Arcieri

[Mark S. Miller]

fil-c vs CHERI?

Google https://www.google.com/search?q=fil-c+vs+CHERI&oq=fil-c+vs+CHERI&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQLhhA0gEIODAzM2owajGoAgCwAgA&sourceid=chrome&ie=UTF-8 finds some opinionated comparisons. 

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CAHOTMVJtL8eKsh%3DbKt9mrBJFcE%2BBgFVi_UYcBhw2XB7%2BHFRZaQ%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Comparing them doesn't make sense to me.  What am I missing?

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/friam/CAK5yZYgo_XUYt%2BqZvCdAHG_mQ4LQWCaD%3Dw_4CRcdEJM53Qtk3w%40mail.gmail.com.

[John Kemp]

Fil-c vs Rust vs CHERI?

One is a approach to taming current untamed C/C++ code. Another is a compile-time approach to memory safety for _new_ code. And the third builds an entirely new memory architecture starting from the hardware?

I think they are all interesting approaches that are aimed at different targets. 

- johnk

To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z10R_P4tUWg8LXy_0eQy44OcmS7yzGfKY01-B79p4dX%3DA%40mail.gmail.com.

[Ben Laurie]

On Fri, 14 Nov 2025 at 11:28, John Kemp <stable.p...@gmail.com> wrote:

Fil-c vs Rust vs CHERI?

One is a approach to taming current untamed C/C++ code. Another is a compile-time approach to memory safety for _new_ code. And the third builds an entirely new memory architecture starting from the hardware?

I think they are all interesting approaches that are aimed at different targets. 

CHERI was certainly not *aimed* at taming C/C++ but it turns out it can do a pretty good job of it, usually with little effort.

I am puzzled by "fil-C doesn't change sizeof(void *)" tho (on the basis of zero research) - if the pointer includes bounds, how can it not grow?

Though someone mentioned garbage collection, so I guess the answer is "indirection"?

I wonder if (and if so, how) fil-C stops me from forging pointers?

 

To view this discussion visit https://groups.google.com/d/msgid/friam/BC629386-DBD4-4BF7-9D0D-E12A6A2A894E%40gmail.com.

[Tom Van Cutsem]

Fil-C's approach is rather well described here, with pointer representation diagrams:

https://fil-c.org/invisicaps

But yes, there's a level of indirection so that the meta-data is not stored as part of the pointer itself.

See here for a list of code examples demonstrating how typical memory-unsafe coding patterns are caught (including forging pointers):

https://fil-c.org/invisicaps_by_example

As for Fil-C vs CHERI, in the author's own words:

"InvisiCaps can also be thought of as a software implementation of CHERI. Unlike CHERI, InvisiCaps are more compatible (pointers are 64-bit, not 128-bit or 256-bit) and InvisiCaps have a more deterministic use-after-free story."

More here: https://news.ycombinator.com/item?id=45570029

As for Fil-C vs Rust: this is comparing apples and oranges. Fil-C is a compiler to make existing C/C++ codebases memory-safe with maximal compatibility in mind, Rust is a modern systems language. The approach is also widely different (runtime checks in Fil-C, versus the borrows checker typesystem in Rust).

KR,

Tom

Op vr 14 nov 2025 om 13:19 schreef 'Ben Laurie' via friam <fr...@googlegroups.com>:

To view this discussion visit https://groups.google.com/d/msgid/friam/CABrd9SQcW8DvdYeD%2BH1oeEAJy5d%3DY82GWGOXG9TZnokgU1vHDA%40mail.gmail.com.

[Tony Arcieri]

On Fri, Nov 14, 2025 at 3:59 PM Tom Van Cutsem <tomv...@gmail.com> wrote:

As for Fil-C vs Rust: this is comparing apples and oranges. Fil-C is a compiler to make existing C/C++ codebases memory-safe with maximal compatibility in mind, Rust is a modern systems language. The approach is also widely different (runtime checks in Fil-C, versus the borrows checker typesystem in Rust).

One of the main things that sets Rust apart is what it’s able to accomplish without GC.

But the last part nails it: Fil-C turns memory safety errors into runtime errors. That’s a great improvement, but you’re still dealing with a buggy program which is crashing at runtime. Whereas in (safe) Rust such errors are compile errors which cause the compiler to reject the program.