[uecker]

It certainly works in my C programs. And Fil-C demos imply that this also works for a lot of other complex real world programs, i.e. a basic Linux distribution with libreoffice on top... So yes, I would say this just works. I agree that catching this at compile-time is better, and to some degree this also works: https://godbolt.org/z/sse74vK9o

Rust does not offer compile-time guarantee that an out-of-bounds access does not panic either.

[dwattttt]

Agreed on the last point. I'm very much in favour of developing an analysis that can assert the absence of an abort, I just can't see how an approach like Fil-C can achieve that.

It can guarantee a potential memory corruption event will be caught at runtime, but at that point I have very limited options.

To be clear, I prefer aborting safely to corrupting memory. But I prefer "issue detected at development time" significantly more than both.

[uecker]

I think we agree on this. Fil-C does not ensure this. Showing the absence of run-time errors at compile-time is a hard problem, and the most realistic solution in general is via model checkers which I think would be the ideal solution, but we would need better tooling. Dependently types languages are also interesting.

In the context of existing tooling and C, there is also a lot of potential in using the optimizer to show safety properties. This works quite well to show the absence of signed overflow issues and null-pointer correctness, but still less well for bounds checking, e.g. see here for some preliminary experiments: https://uecker.codeberg.page/2026-05-22.html