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

Posted Oct 28, 2025 19:55 UTC (Tue) by oldnpastit (subscriber, #95303)
Parent article: Fil-C: A memory-safe C implementation

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

to post comments

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

Posted Oct 28, 2025 20:28 UTC (Tue) by bertschingert (subscriber, #160729) [Link]

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?

Posted Oct 28, 2025 20:33 UTC (Tue) by excors (subscriber, #95769) [Link] (4 responses)

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?

Posted Oct 28, 2025 21:26 UTC (Tue) by cyperpunks (subscriber, #39406) [Link] (3 responses)

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?

Posted Oct 29, 2025 4:57 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Yes, it can be thought about like this. Fil-C limits the primitives that are accessible to the C code so that no combination of them can (in theory) lead to memory safety issues.

It's somewhat analogous to compiling C into WebAssembly and then JIT-compiling WebAssembly.

The amazing thing is that it preserves most of C/C++ semantics.

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

Posted Oct 29, 2025 5:53 UTC (Wed) by willmo (subscriber, #82093) [Link] (1 responses)

> The amazing thing is that it preserves most of C/C++ semantics.

But (at least WRT memory safety) only the semantics of the abstract machine described by the language standards, and not the additional semantics (aka undefined behavior) of the straightforward mappings to typical hardware that we’re all accustomed to.

Very cool idea. :-)

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

Posted Oct 30, 2025 15:00 UTC (Thu) by atanasi (guest, #136067) [Link]

Fil-C strives to support undefined behavior:

'In addition to memory safety, Fil-C's other goal is fanatical compatibility. This means that Fil-C's capability model also has to allow most (or ideally all) "safe" uses of C pointers; that is, idioms that are in widespread use and don't lead to exploitation unless they violate the above rules. This means even supporting uses of pointers that the C spec deems to be undefined behavior.'

How is this different from SoftBound+CETS?

Posted Nov 25, 2025 11:19 UTC (Tue) by gmatht (subscriber, #58961) [Link]

This seems a lot more similar to SoftBound+CETS than Valgrind.

When would you use Fil-C instead of S+CETS? (or visa versa for that matter).