A simplified model of Fil-C

aaw1621107 about 3 hours ago 41 commentsRead Article on corsix.org

FR version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

38% Positive

Analyzed from 615 words in the discussion.

Discussion (41 Comments)Read Original on HackerNews

whatsakandr•about 2 hours ago

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.

omcnoe•about 2 hours ago

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•about 2 hours ago

For some things the just-crash is ok, like cli usage of curl

gnabgib•about 2 hours ago

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•about 2 hours ago

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•about 2 hours ago

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•about 2 hours ago

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

dataflow•about 2 hours ago

> 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•about 2 hours ago

Exactly, the Venn diagram of programmers using c/c++ and programmers who can use a garbage collector for their workload is two circles.

kbolino•about 2 hours ago

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•about 2 hours ago

> it slows programs down

Interesting, how costly would be hardware acceleration support for Fil-C code.

kbolino•about 2 hours ago

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_Enhanced_R...

[2]: https://go.dev/blog/greenteagc

pizlonator•about 2 hours ago

You’re not wrong but both problems could be alleviated by sending patches :-)

kbolino•about 2 hours ago

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•about 2 hours ago

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.

GaggiX•about 2 hours ago

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.

vzaliva•about 2 hours ago

This is yet another variant of the "fat pointers" technique, which has been implemented and rejected many times due to either insufficient security guarantees, inability to cross non-fat ABI boundaries, or the overhead it introduces.