Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes by djb on using Fil-C

cr.yp.to

Post reply on HN
Print view View original

201–210 of 263 posts

Re: Notes by djb on using Fil-C

#201

Post by int_19h »

quotemstr wrote: post #65

I can't wait for all the delicious four-way flamewars. Choose your fighter! 1) Rewrite X in Rust 2) Recompile X using Fil-C 3) Recompile X for WASM 4) Safety is for babies There are a lot of half baked Rust rewrites whose existence was justified on safety grounds and whose rationale is threatened now that HN has heard of Fil-C

It's not an either-or (well, except for this last item).

It seems sensible to not write new software in plain C. Rust is certainly a valid choice for a safer language, but in many cases overkill wrt how painful the rewrite is vs benefits gained from avoiding a higher-level memory-safe one like OCaml.

At the same time, "let's just rewrite everything!" is also madness. We have many battle-tested libraries written in C already. Something like Fil-C is badly needed to keep them working while improving safety.

And as for wasm, it's sort of orthogonal - whether you're writing in C or in Rust, the software may be bug-free, but sandboxing it may still be desirable e.g. as a matter of trust (or lack thereof). Also, cross-platform binaries would be nice to have in general.

Re: Notes by djb on using Fil-C

#202

Post by jitl »

kragen wrote: post #179
quotemstr wrote: post #162

Earlier quoted context omitted.

It depends. Consider DuckDB or another heavily vectorized columnar DB: there's a big part of the system (SQL parser, storage chunk manager, etc.) that's not especially performance-sensitive and a set of tiny, fast kernels that do things like predicate-push-down-based full table scans, ART lookups, and hash table creation for merge joins. DuckDB is a huge pile of C++. I don't see a RIIR taking off before AGI. But you…

> DuckDB is a huge pile of C++. I don't see a RIIR taking off before AGI. While I'm not a big fan of rewriting things, all of DuckDB has been written in the last 10 years. Surely a rewrite with the benefit of hindsight could reach equivalent functionality in less than 10 years?

the sqlite RIIR is going quite well: https://turso.tech/blog/beyond-the-single-writer-limitation-...

(sqlite is quite a bit smaller than DuckDB tho)

Re: Notes by djb on using Fil-C

#203

Post by fngjdflmdflg »

jeffjeffbear wrote: post #195
fngjdflmdflg wrote: post #181

Is there a reason that some of the linked benchmarks, if I'm reading it right, have Fil-C running faster than C?[0] I assume it's just due to micro-benchmark variability but I'm curious. Some of them seem impossibly fast compared to C so I wonder if there are some correctness issue there. [0] https://cr.yp.to/2025/20251028-filcc-vs-clang.html

Usually garbage collection does improve alot of benchmarks, just look at the hans boem gc benchmarks.

The two extreme outliers I see are labeled "aead/clx192q/opt,-O3" and "aead/schwaemm128128v2/opt,-Os" according to clicking on the points with devtools. aead/schwaemm128128v2/opt,-Os looks like it is almost at 0x. 1x is at about y = 659 and that test is at 769 out of I guess 780 based on the graph.

Re: Notes by djb on using Fil-C

#204

Post by kragen »

jitl wrote: post #202
kragen wrote: post #179

Earlier quoted context omitted.

> DuckDB is a huge pile of C++. I don't see a RIIR taking off before AGI. While I'm not a big fan of rewriting things, all of DuckDB has been written in the last 10 years. Surely a rewrite with the benefit of hindsight could reach equivalent functionality in less than 10 years?

the sqlite RIIR is going quite well: https://turso.tech/blog/beyond-the-single-writer-limitation-... (sqlite is quite a bit smaller than DuckDB tho)

Is it? It's much less new.

Re: Notes by djb on using Fil-C

#205

Post by MangoToupe »

thesz wrote: post #119
pornel wrote: post #116

Earlier quoted context omitted.

Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.

From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most inter…

What does "significantly" mean to you? To my ear, "significantly" means "statistically significant".

Re: Notes by djb on using Fil-C

#206

Post by jitl »

transpute wrote: post #193
dang wrote: post #128

Related: Fil-C: A memory-safe C implementation - https://news.ycombinator.com/item?id=45735877 - Oct 2025 (130 comments) Safepoints and Fil-C - https://news.ycombinator.com/item?id=45258029 - Sept 2025 (44 comments) Fil's Unbelievable Garbage Collector - https://news.ycombinator.com/item?id=45133938 - Sept 2025 (281 comments) InvisiCaps: The Fil-C capability model - https://news.ycombinator.com/item?id=45123672 - Sep…

Thanks for the subthread discussion links, e.g. authors of LuaJIT and Fil-C, https://news.ycombinator.com/item?id=40556083 (June 2024)

Mike Pall is the author of LuaJIT.

Re: Notes by djb on using Fil-C

#207

Post by kragen »

pizlonator wrote: post #192
skissane wrote: post #174

Earlier quoted context omitted.

> Like Java, you can just `new` or `malloc` without `delete`ing or `free`ing. Is your intention that people use the Fil-C garbage collector instead of free()? Or is it just a backstop in case of memory leak bugs? Can the GC be configured to warn or panic if something is GCed without free()? Then you could detect memory leak bugs by recompiling with Fil-C - with less overhead than valgrind, although I’m guessing still…

> Is your intention that people use the Fil-C garbage collector instead of free()? Or is it just a backstop in case of memory leak bugs? Wow great question! My intention is to give folks powerful options. You can choose: - Compile your code with Fil-C while still maintaining it for Yolo-C. In that case, you'll be calling free(). Fil-C's free() behavior ensures no GC-induced leaks (more on that below) so code that doe…

Okay, that's brilliant. I didn't even imagine that the GC-induced leak problem was even solvable. I guess the freed-but-not-GCed object could be arbitrarily large, but that's almost never going to be a gradual leak.

What's awesome about the Emacs GC?

Re: Notes by djb on using Fil-C

#208

Post by jitl »

gkfasdfasdf wrote: post #190

Does Fil-C catch uninitialized memory reads?

malloc'd memory is zeroed in fil-c:

> *zgc_alloc*

> Allocate count bytes of zero-initialized memory. May allocate slightly more than count, based on the runtime's minalign (which is currently 16).

> This is a GC allocation, so freeing it is optional. Also, if you free it and then use it, your program is guaranteed to panic.

> libc's malloc just forwards to this. There is no difference between calling malloc and zgc_alloc.

from https://fil-c.org/stdfil

Re: Notes by djb on using Fil-C

#209

Post by kragen »

Findecanor wrote: post #178
kragen wrote: post #24

Earlier quoted context omitted.

So far we haven't found a viable alternative; CHERI has holes in its temporal integrity guarantees.

Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool. The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet. I'…

I didn't know this, but aside from the GC, Fil-C promptly revokes capabilities to freed objects, not relying on a concurrent task to do it eventually; CHERI cannot AFAIK.

Re: Notes by djb on using Fil-C

#210

Post by vacuity »

simonask wrote: post #182
mbrock wrote: post #77

Earlier quoted context omitted.

Hmm, so if they're writing new memory unsafe code in C/C++, presumably to remain within their already established and entrenched C/C++ ecosystems, why isn't Fil-C interesting as a way to thwart memory safety issues in that new code?

Because every problem detected by Fil-C is already a serious problem in the existing code. As a mitigation strategy, that becomes less interesting as the quality of that code increases, but you still pay the full cost regardless of whether there are actually any bugs. That can certainly be valuable to you, but as a developer, the more interesting proposition is about how not to ship bugs in the first place.

As others have said, programs that have already been written are plainly not in the business of "not...[shipping] bugs in the first place". New code is new code; old code is old code.
Post reply on HN