Hacker News new | ask | show | jobs
by dwattttt 3 days ago
> Regarding the silly point: Fil-C is less of a rock than Safe Rust as everything in C just works.

I'm going to challenge this. Is this from your experience? InvisiCaps, which Fil-C is based on, turns out of bounds accesses into panics. You're saying that turning any "benign" out of bounds into "abort the program" in all the C you? anyone? everyone? uses Just Works?

I'd rather the majority of those failure modes be caught by linters/compiler passes, not runtime safe aborts.
1 comments
uecker 3 days ago
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.

link
dwattttt 3 days ago
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.

link
uecker 2 days ago
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

link