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

111–120 of 263 posts

Re: Notes by djb on using Fil-C

#111

Post by thomasmg »

commandersaki wrote: post #23
testdelacc1 wrote: post #11

For those, like me, that didn’t know what Fil-C is: > Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (InvisiCaps). Every possibly-unsafe C and C++ operation is che…

I guess to get on board with this, it is my understanding you have to accept the premise of a Garbage Collector in the runtime?

The author of Fil-C does have some ideas to avoid a garbage collector [1], in summary: Use-after-free at worst means you might see an object of the same size, but you can not corrupt data structures (no pointer / integer confusion). This would be more secure than standard C, but less secure than Fil-C with GC.

[1] https://x.com/filpizlo/status/1917410045320650839

Re: Notes by djb on using Fil-C

#112

Post by Klonoar »

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

Fil-C has come up on HN plenty of times before. If it was going to make much of a dent in the discussions, it would have by now.

Re: Notes by djb on using Fil-C

#114

Post by quotemstr »

Klonoar wrote: post #112
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

Fil-C has come up on HN plenty of times before. If it was going to make much of a dent in the discussions, it would have by now.

It's strange how ideas seem to explode at random into the discourse despite being known for a long time. It's as if some critical mass stumbles on a thing and it becomes "the current thing" everyone talks about until the next current thing.

Re: Notes by djb on using Fil-C

#115

Post by [deleted] »

vorador wrote: post #90
mbrock wrote: post #46

Earlier quoted context omitted.

I don't understand the need to hammer in the point that Fil-C is only valuable for this tiny, teeny, irrelevant microscopic niche, while not even talking about what the niche is? To be clear, the niche is rebuilding your entire GNU/Linux userland with full memory safety and completely acceptable performance, tomorrow, without rewriting anything, right? Is this such a silly little idiosyncratic hobby?

There's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust. Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.

[deleted]

Re: Notes by djb on using Fil-C

#116

Post by pornel »

lquidfire wrote: post #113

Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wonder how / where Epic Games comes in?

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.

Re: Notes by djb on using Fil-C

#117

Post by pas »

bgwalter wrote: post #100
pas wrote: post #74

Earlier quoted context omitted.

Sorry, can you explain what he did to himself?

I would like to know as well. All that is public is that a couple of IETF apparatchiks want to ban him for criticizing corporate and NSA influence: https://web.archive.org/web/20250513185456/https://mailarchi... The IETF has now accepted the required new moderation guidelines, which will essentially be a CoC troika that can ban selectively: https://mailarchive.ietf.org/arch/msg/mod-discuss/s4y2j3Dv6D... It is very sa…

... if he thinks some WG is making a mistake and he's not welcome there (everyone else seems to be okay with what's happening based on the quoted email on the first link), then - CoC or not - he should then leave, and publicly post distance himself from the outcome.

(Obviously he was never the one to back down from a just fight, but it's important to find the right hill to die on. And allies! And him not following RFC 2026 [from 1996, hardly the peak of Internet bureaucracy] is not a CoC thing anyway.)

Re: Notes by djb on using Fil-C

#118

Post by OmarAssadi »

EPWN3D wrote: post #79
simonask wrote: post #44

Earlier quoted context omitted.

If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally…

Even if you can't use something like Fil-C in your release/production builds, being able to e.g. compile unit tests with it to catch memory safety bugs is a huge win. My team use gcc for its mips codegen, but I'm working on adopting the clang bounds-safety annotations for test builds for exactly this reason.

Yeah, I haven't yet taken a serious look into it from that perspective yet, but similar came to mind; while, outside of bootstrapping the JDK from GCJ, Boehm GC hasn't been super relevant to me for "release" builds of anything, it's been useful in leak detection mode on occasion.

I figure even if you cannot use, or do not want to use, something like Fil-C in production, there's solid potential for it to augment whatever existing suite of sanitizers and other tools that one may already build against.

Re: Notes by djb on using Fil-C

#119

Post by thesz »

pornel wrote: post #116
lquidfire wrote: post #113

Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wonder how / where Epic Games comes in?

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 interpreters are. The ROOT C/C++ interpreter is 20+ times slower than binary code, for example.

Re: Notes by djb on using Fil-C

#120

Post by loeg »

1vuio0pswjnm7 wrote: post #88

For those who might miss it, the notes cite a new 64-bit version of cdb that supports exabyte databases https://cdb.cr.yp.to Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve

https://news.ycombinator.com/item?id=45663435 (discussed 11d ago)
Post reply on HN