A simplified model of Fil-C

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

⚡ Community Insights

Discussion Sentiment

52% Positive

Analyzed from 1362 words in the discussion.

Discussion (46 Comments)Read Original on HackerNews

whatsakandr•about 2 hours ago

Fil-C is one of the most underrated 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.

tialaramex•about 1 hour ago

So, a few things, some of which others have touched on:

1. Fil-C is slower and bigger. Noticeably so. If you were OK with slower and bigger then the rewrite you should have considered wasn't to Rust in the last ten years but to Java or C# much earlier. That doesn't invalidate Fil'C's existence, but I want to point that out.

2. You're still writing C. If the program is finished or just occasionally doing a little bit of maintenance that's fine. I wrote C for most of my career, it's not a miserable language, and you are avoiding a rewrite. But if you're writing much new code Rust is just so much nicer. I stopped writing any C when I learned Rust.

3. This is runtime safety and you might need more. Rust gives you a bit more, often you can express at compile time things Fil-C would only have checked at runtime, but you might need everything and languages like WUFFS deliver that. WUFFS doesn't have runtime checks. It has proved to its satisfaction during compilation that your code is safe, so it can be executed at runtime in absolute safety. Your code might be wrong. Maybe your WUFFS GIF flipper actually makes frog GIFs purple instead of flipping them. But it can't crash, or execute x86 machine code hidden in the GIF, or whatever, that's the whole point.

whatsakandr•6 minutes ago

Yes it's slower, but it works. It's being built by one single dad who focused on compatibility before speed.

I'm not convinced that tying the lifetimes into the type system is the correct way to do memory management. I've read too many articles of people being forced into refactoring the entire codebase to implement a feature.

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

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.

pizlonator•about 2 hours ago

> write memory-unsafe code, just now it is guaranteed to crash

If it's guaranteed to crash, then it's memory-safe.

If you dislike that definition, then no mainstream language is memory-safe, since they all use crashes to handle out of bounds array accesses

omcnoe•about 1 hour ago

I don't think that's a useful way of thinking about memory-safety - a C compiler that compiles any C program to `main { exit(-1); }` is completely memory-safe. It's easy to design a memory-safe language/compiler, the question is what compromises are being made to achieve it.

Other languages have runtime exceptions on out-of-bounds access, Fil-C has unrecoverable crashes. This makes it pretty unsuitable to a lot of use cases. In Go or Java (arbitrary examples) I can write a web service full of unsafe out-of-bounds array reads, any exception/panic raised is scoped to the specific malformed request and doesn't affect the overall process. A design that's impossible in Fil-C.

ori_b•about 1 hour ago

By that token, Rust is also memory unsafe: array bounds checks and stack overflow are runtime checks.

p1necone•33 minutes ago

Why are you talking like this is black and white? Many things being compile time checkable is better than no things being compile time checkable. The existence of some thing in rust that can only be checked at runtime does not somehow make all the compile time checks that are possible irrelevant.

(Also I think the commenter you're replying to just worded their comment innacurately, code that crashes instead of violating memory safety is memory safe, a compilation error would just have been more useful than a runtime crash in most cases)

DetroitThrow•about 1 hour ago

There are several ways to safely provide array bounds check hints to the Rust compiler, in-fact there's a whole cookbook. But for many cases, yep, runtime check.

100ms•about 1 hour ago

What's the alternative?

https://play.rust-lang.org/?version=stable&mode=debug&editio...

omcnoe•about 1 hour ago

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Catch the panic & unwind, safe program execution continues. Fundamentally impossible in Fil-C.

zamadatix•about 1 hour ago

.get() will bounds check and the compiler will optimize that away if it can prove safety at compile time. That leaves you 3 options made available in Rust:

- Explicitly unsafe

- Runtime crash

- Runtime crash w/ compile time avoidence when possible

boredatoms•about 2 hours ago

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

forrestthewoods•about 1 hour ago

Rust also has run-time crash checks in the form of run-time array bounds checks that panic. So let us not pretend that Rust strictly catches everything at compile-time.

It’s true that, assuming all things equal, compile-time checks are better than run-time. I love Rust. But Rust is only practical for a subset of correct programs. Rust is terrible for things like games where Rust simply can not prove at compile-time that usage is correct. And inability to prove correctness does NOT imply incorrectness.

I love Rust. I use it as much as I can. But it’s not the one true solution to all things.

omcnoe•about 1 hour ago

Not trying to be a Rust advocate and I actually don't work in it personally.

But Rust provides both checked alternatives to indexed reads/writes (compile time safe returning Option<_>), and an exception recovery mechanism for out-of-bounds unsafe read/write. Fil-C only has one choice which is "crash immediately".

wakawaka28•about 1 hour ago

>And inability to prove correctness does NOT imply incorrectness.

And inability to prove incorrectness does NOT imply correctness. I think most Rust users don't understand either, because of the hype.

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.

pizlonator•about 2 hours ago

Except for:

- Me. I'm a C++ programmer.

- Any C++ programmer who has added a GC to their C++ program. (Like the programmers who used the web browser you're using right now.)

- Folks who are already using Fil-C.

adamnemecek•15 minutes ago

It really doesn't, Rust is a better language.

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.

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.

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

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.

DetroitThrow•about 1 hour ago

I write C++ for my job everyday, and claiming Fil-C does the same thing as Rust (and that people who do rewrites in Rust are stupid) sounds braindead.

I love Fil-C. It's underrated. Not the same niche as Rust or Ada.

andai•3 minutes ago

Tell me more about Ada!

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.