[HN Gopher] A simplified model of Fil-C
___________________________________________________________________
A simplified model of Fil-C
Author : aw1621107
Score : 50 points
Date : 2026-04-17 21:38 UTC (1 hours ago)
(HTM) web link (www.corsix.org)
(TXT) w3m dump (www.corsix.org)
| whatsakandr wrote:
| Fil-C is one of the most unrated projects I've ever seen. All
| this "rewrite it in rust for safety" just sounds stupid when you
| can compile your C program completely memory safe.
| gnabgib wrote:
| Not here, lots of discussion:
|
| _Fil-Qt: A Qt Base build with Fil-C experience_ (143 points, 3
| months ago, 134 comments)
| https://news.ycombinator.com/item?id=46646080
|
| _Linux Sandboxes and Fil-C_ (343 points, 4 months ago, 156
| comments) https://news.ycombinator.com/item?id=46259064
|
| _Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C_
| (67 points, 5 months ago, 56 comments)
| https://news.ycombinator.com/item?id=46090009
|
| _A Note on Fil-C_ (241 points, 5 months ago, 210 comments)
| https://news.ycombinator.com/item?id=45842494
|
| _Notes by djb on using Fil-C_ (365 points, 6 months ago, 246
| comments) https://news.ycombinator.com/item?id=45788040
|
| _Fil-C: A memory-safe C implementation_ (283 points, 6 months
| ago, 135 comments)
| https://news.ycombinator.com/item?id=45735877
|
| _Fil 's Unbelievable Garbage Collector_ (603 points, 7 months
| ago, 281 comments)
| https://news.ycombinator.com/item?id=45133938
| pizlonator wrote:
| Thanks for the love man!
|
| > "rewrite it in rust for safety" just sounds stupid
|
| To be fair, Fil-C is quite a bit slower than Rust, and uses
| more memory.
|
| On the other hand, Fil-C supports safe dynamic linking and is
| strictly safer than Rust.
|
| It's a trade off, so do what you feel
| masfuerte wrote:
| Minor nitpick. Or confusion on my part. In the filc_malloc
| function the call to calloc doesn't seem to allocate enough
| memory to store an AllocationRecord for each location in
| visible_bytes. Should it be:
| ar->invisible_bytes = calloc(length,
| sizeof(AllocationRecord));
| pizlonator wrote:
| Note, I'm not the author of the OP.
|
| I am the author of Fil-C
|
| If you want to see my write-ups of how it works, start
| here: https://fil-c.org/how
| kbolino wrote:
| Fil-C has two major downsides: it slows programs down and it
| doesn't interoperate with non-Fil-C code, not even libc. That
| second problem complicates using it on systems other than Linux
| (even BSDs and macOS) and integrating it with other safe
| languages.
| kvemkon wrote:
| > it slows programs down
|
| Interesting, how costly would be hardware acceleration
| support for Fil-C code.
| kbolino wrote:
| I think there's two main avenues for hardware acceleration:
| pointer provenance and garbage collection. The first
| dovetails with things like CHERI [1] but the second doesn't
| seem to be getting much hardware attention lately. It has
| been decades since Lisp Machines were made, and I'm not
| aware of too many other architectures with hardware-level
| GC support. There are more efficient ways to use the
| existing hardware for GC though, as e.g. Go has
| experimented with recently [2].
|
| [1]: https://en.wikipedia.org/wiki/Capability_Hardware_Enha
| nced_R...
|
| [2]: https://go.dev/blog/greenteagc
| pizlonator wrote:
| You're not wrong but both problems could be alleviated by
| sending patches :-)
| kbolino wrote:
| I would never say it's impossible, and you've done some
| amazing work, but I do wonder if the second problem is
| feasibly surmountable. Setting aside cross-language
| interop, BYOlibc is not really tolerated on most systems.
| Linux is fairly unique here with its strongly compatible
| syscall ABI.
| rvz wrote:
| It makes more sense for _new_ software to be written in Rust,
| rather than a full rewrite of existing C /C++ software to Rust
| in the same codebase.
|
| Fil-C just does the job with existing software in C or C++
| without an expensive and bug riddled re-write and serves as a
| quick protection layer against the common memory corruption
| bugs found in those languages.
| dataflow wrote:
| > Fil-C is one of the most unrated projects I've ever seen
|
| When's the last time you told a C/C++ programmer you could add
| a garbage collector to their program, and saw their eyes light
| up?
| FuckButtons wrote:
| Exactly, the Venn diagram of programmers using c/c++ and
| programmers who can use a garbage collector for their
| workload is two circles.
| GaggiX wrote:
| Fil-C is much slower, no free lunch, if you want the language
| to be fast and memory safe you need to add restrictions to
| allow proper static analysis of the code.
| omcnoe wrote:
| The issue with Fil-C is that it's runtime memory safety. You
| can still write memory-unsafe code, just now it is guaranteed
| to crash rather than being a potential vulnerability.
|
| Guaranteed memory safety at compile time is clearly the better
| approach when you care about programs that are both
| functionally correct and memory safe. If I'm writing something
| that takes untrusted user input like a web API memory safety
| issues still end up as denial-of-service vulns. That's better,
| but it's still not great.
|
| Not to disparage the Fil-C work, but the runtime approach has
| limitations.
| boredatoms wrote:
| For some things the just-crash is ok, like cli usage of curl
___________________________________________________________________
(page generated 2026-04-17 23:00 UTC)