LWN: Comments on "Fil-C: A memory-safe C implementation"

Fil-C for programmers

rahulsundaram — Wed, 29 Oct 2025 01:35:14 +0000

Fair point. Reducing friction to adoption could work if the performance impact is universally close enough.

How is this different from tools like Valgrind and Address Sanitizer?

cyperpunks — Tue, 28 Oct 2025 21:26:50 +0000

So it's kind of small virtual machine with garbage collection that happens to be compatible with C/C++ based source code?

How is this different from tools like Valgrind and Address Sanitizer?

excors — Tue, 28 Oct 2025 20:33:26 +0000

From the readme:

> Fil-C is engineered to prevent memory safety bugs from being used for exploitation rather than just simply flagging them often enough to find bugs. This makes Fil-C different from AddressSanitizer, HWAsan, or MTE, which can all be bypassed by attackers. The key difference that makes this possible is that Fil-C is capability based (so each pointer knows what range of memory it may access, and how it may access it) rather than tag based (where pointer accesses are allowed if they hit valid memory).

Clang says "AddressSanitizer's runtime was not developed with security-sensitive constraints in mind and may compromise the security of the resulting executable", so it should not be used in production.

Valgrind has much worse performance (the manual claims 10-50x slowdown, plus it's effectively single-threaded), which is probably bad enough to make it unusable in production, and similarly will miss many memory safety bugs.

How is this different from tools like Valgrind and Address Sanitizer?

bertschingert — Tue, 28 Oct 2025 20:28:01 +0000

Fil-C seems to be more similar to ASAN than Valgrind in that the compiler outputs code with the instrumentation / checking present, rather than running already compiled code in a virtual machine as Valgrind does.

But it would seem to be more robust than ASAN; from reading about how ASAN works, it seems that it puts "poisoned" bytes around an allocation, so that memory accesses shortly after the end of a buffer hit those poisoned bytes and are caught. However, ASAN wouldn't catch an invalid access to a non-poisoned address of memory via a particular a pointer, if that address was allocated in a separate allocation. [1]

I assume Fil-C's pointer capability model is able to catch "provenance" violations like that.

[1] https://blog.gistre.epita.fr/posts/benjamin.peter-2022-10...

How is this different from tools like Valgrind and Address Sanitizer?

oldnpastit — Tue, 28 Oct 2025 19:55:23 +0000

This seems to be run-time (as opposed to compile-time checking) - i.e. what Valgrind and ASAN do. Or have I misunderstood it?

Fil-C for programmers

rweikusat2 — Tue, 28 Oct 2025 18:34:02 +0000

If this is just another C implementation, it's distribution packagers who would need to adopt it and possibly other people who routinely compile but not necessarily write code.

Fil-C for programmers

daroc — Tue, 28 Oct 2025 18:32:49 +0000

I think the point of Fil-C, as a C implementation, is precisely to support the people and projects that are just going to keep using C — in a way that still lets users avoid memory safety issues if they so choose.

Fil-C for programmers

rahulsundaram — Tue, 28 Oct 2025 18:15:19 +0000

> I am interested in programmers rather than users because I think that influences whether Fil-C is just an interesting project for our moment or it becomes a "successor" to C in a way that Zig, Odin etc. never could.

My expectation is that there isn't going to be a single successor to C. For some group of people, that was C++ a long time back. For others it is going to Rust or Zig or something else. For the final group they are going to keep coding in C forever and it will more of a generational change eventually.

Fil-C for programmers

tialaramex — Tue, 28 Oct 2025 17:54:57 +0000

I'm interested in adoption of Fil-C by C and C++ programmers because for some years my assumption has been that most remaining C programmers in particular want DWIM and so they won't be any happier in Fil-C than in say (safe) Rust since these languages both lack the unconstrained Undefined Behaviour where DWIM thrives, if you write nonsense in Fil-C your program doesn't work and it's your fault which presumably was not what you meant. So widespread enthusiasm for Fil-C from C programmers would indicate that I was completely wrong, which would be a pleasant surprise.

For users in a bunch of cases this is a no brainer, Daroc gave their shell as an example but I'm sure most of us run many programs every day where raw perf just isn't a big deal. I am interested in programmers rather than users because I think that influences whether Fil-C is just an interesting project for our moment or it becomes a "successor" to C in a way that Zig, Odin etc. never could.