Did this find bugs?

Posted Oct 29, 2025 8:11 UTC (Wed) by marcH (subscriber, #57642)
Parent article: Fil-C: A memory-safe C implementation

Did this find memory bugs in existing code much? I mean the type of memory corruption that you often get away with, like use after free for a little while.

to post comments

Did this find bugs?

Posted Oct 29, 2025 16:35 UTC (Wed) by mb (subscriber, #50428) [Link] (2 responses)

This doesn't look like it is about finding bugs, but rather about mitigating the effects of exploiting zero day bugs.

Did this find bugs?

Posted Oct 29, 2025 17:10 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses)

Whatever the primary goal is, it should help find bugs, no?

Did this find bugs?

Posted Nov 2, 2025 11:47 UTC (Sun) by cpitrat (subscriber, #116459) [Link]

Disclaimer: I know nothing about FilC, I discovered it with this article. This is just the result of searching the web for 10 minutes.

The FilC website or git repo, surprisingly, don't seem to give an example of what FilC catching a bug looks like. However I found this YouTube video in which the author does a demo: https://youtu.be/Gij9UQy_JEQ

You can see that, although FilC detects the issues and interrupts the program, the output is not extremely useful when it comes to identifying the source of the bug. Once you hit an issue, you're probably better off using valgrind or asan to find out what went wrong and fix the bug.

I didn't find anything about compiling options (e.g. debug build, including symbols, ...) which would improve the output, for example by outputting a stack of where the error occurred. This is likely feasible, but this doesn't seem to be the main focus of the project, at least at the moment.