Earlier quoted context omitted.
He's been especially arrogant and dismissive on X. I'm very glad Fil-C exists, but his behavior makes me doubt the whole project.
Mark? AwareDigital 2013?
Hey drop me an email
Fil-C: Garbage In, Memory Safety Out [video]
171–180 of 190 posts
Re: Fil-C: Garbage In, Memory Safety Out [video]
#172Who is the author of this project? Is it a single person? A small team? A single person with LLMs?
Filip Pizło (https://www.filpizlo.com/), according to his website: Director of Programmability and Data Model at Roblox. Previously, I worked at Epic Games (Senior Director of Language Engineering) and Apple (Manager of the JavaScriptCore Team).
He seems to be the main developer of Fil-C: https://github.com/pizlonator/fil-c although there are other contributors.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#173Earlier quoted context omitted.
> Someone in the audience also pointed out that a tool like this could be used to compile rust programs, not just C programs, in which case it's odd to hear Fil-C repeatedly framed as a language in opposition to rust rather than as a tool which might complement it. You can combine both approaches for sure, but that doesn't change that they are indeed separate approaches. One (Rust) intends to characterize and prevent…
Arguably the most important memory safety property, i.e. bounds checking for dynamic arrays, is also not statically checked in Rust.
But that's also arguably pretty boring because it's very easy to dynamically check and the cost for doing so is relatively small compared to what needs to be done for other properties.
On the other hand statically checking bounds for (dynamic and non) arrays is very very hard in the general case.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#174Earlier quoted context omitted.
Not the person you're asking, but result types pessimize code more, add register pressure, use more icache for largely dead code, etc. They're arguably noisier at the source level too. That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Heck, C++'s "noexcept" is a strong argument against exceptions all by itself.
> That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Yes. This is why unchecked exceptions are annoying. Checked exceptions are a „failed experiment“ anyway. A result type (or even Go‘s err) with forced error handling meaningfully increases the robustness of a program in my experience.
Checked exceptions were actually the "right way" to do exceptions (if there is such a thing), the problem was just that developers hated them, but I think that draws the wrong conclusion. That tells me their syntax/usage was seen as too much forced boiler plate making code unwieldy, not that they didn't have benefits for correctness (something often not appreciated until years later).
Unchecked exceptions lead to unhandled exceptions at runtime. We've all seen screens with Java programs running with tons of exceptions in the log, or worse, that crash with unhandled exceptions. This is the result of the unchecked exceptions mess, which is why I won't use languages that use them for routine error handling for anything more than trivial programs.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#175Earlier quoted context omitted.
That's a lot of words to say that the problem with Rust is that people you don't like are allowed to write unsafe code.
My god, you are insufferable, that's not my opinion at all. Just because I used quotation marks in one place, a practice that can convey multiple meanings, not all of which involve disdain. It's unfortunate that Rust, a good language that has more practical use than Fil-C, a language that I use more than Fil-C, has proselytizers such as you.
Your argument is literally that there is too much unsafe code.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#176Earlier quoted context omitted.
I thought it was very obvious throughout the video what was happening... Rust has compile time checks to enforce some safety. In comparison Fil-C is a lot more memory safe, it's more comparable to being a software implementation of CHERI. Unfortunately it comes with downsides: runtime performance, runtime enforcement, granular safety (the safety is around allocations). It also comes with huge upsides: you can run C/C…
I'm not a native English speaker, I know "memory safe" has a precise technical meaning, but the word "safe" still feels a bit strange to me given that a memory-safety bug can make the program crash at run-time. Sure, Fil-C prevents the bug from possibly being exploited, which is a huge improvement. But crashing can be a DoS attack, and if running a mission-critical system, it might not be an acceptable outcome. I jus…
Even in memory safe Rust, out-of-bounds array access also results in crashes.
The whole point of memory safety is that bugs can not be exploited. A memory safe program does not mean a crash safe program.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#177Who is the author of this project? Is it a single person? A small team? A single person with LLMs?
Filip mentioned in the talk that Fil-C is his personal project.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#178Earlier quoted context omitted.
> That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Yes. This is why unchecked exceptions are annoying. Checked exceptions are a „failed experiment“ anyway. A result type (or even Go‘s err) with forced error handling meaningfully increases the robustness of a program in my experience.
Checked exceptions were actually the "right way" to do exceptions (if there is such a thing), the problem was just that developers hated them, but I think that draws the wrong conclusion. That tells me their syntax/usage was seen as too much forced boiler plate making code unwieldy, not that they didn't have benefits for correctness (something often not appreciated until years later). Unchecked exceptions lead to unh…
> developers hated them, but I think that draws the wrong conclusion
Exception handling is just annoying from a syntax perspective. Also checked Exceptions have the problem that they bubble up types that a different layer shouldn’t even be aware of due to exception chaining (cause of a cause etc), unless you carefully re-throw them, which nobody did.
Lower ceremony errors are just better to deal with.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#179Earlier quoted context omitted.
A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.
No, that's not how this works. The bug being utilized by cve-rs has such roundabout requirements that it's unlikely that anyone has ever triggered it without trying (to be clear, the Rust devs plan to fix it regardless). Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...
I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them:
• `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`.
• `std::env::set_var(...)`. It's now marked `unsafe`. While I dodged the bullet, these fellows didn't: https://www.geldata.com/blog/c-stdlib-isn-t-threadsafe-and-e...
• `#[no_mangle]`. It's now `#[unsafe(no_mangle)]`.
I don't believe I've constructed cvs-rs's hole by accident. cve-rs's code links to https://github.com/rust-lang/rust/issues/25860 , which is admittedly still open after a decade. Progress appears to still be ongoing though! Related:
• https://github.com/orgs/rust-lang/projects/44/views/1
• https://rust-lang.github.io/rust-project-goals/2025h2/next-s...
> Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: [...]
Thanks for sharing a concrete example of Fil-C's limitations! Disappointing - but not unexpected - to see it underperforming existing sanitizers. I was hoping for better.
Re: Fil-C: Garbage In, Memory Safety Out [video]
#180Earlier quoted context omitted.
> python is gonna be the easier option 99% of the time If python/go/C# is easier to write, why choose C? Fil-C removes C’s performance and interoperability advantages.
Python is easier to write for interview questions. It generally doesn't scale well (in terms of size of team and codebase). TBH C# is probably a good default for a lot of projects, from a safety and performance standpoint (rust's big performance win over GC/JIT languages is more in the memory consumption than throughput, counterintuitively). Fil-C probably still has a pretty good edge on python's performance, though.
> Fil-C probably still has a pretty good edge on python's performance, though.
Probably - but where are the benchmarks?
> Python […] generally doesn't scale well (in terms of size of team and codebase).
I’d argue neither does C. Everyone works around C’s lack of generics in their own way, so every large project becomes its own little world.
C’s biggest scalability problem is its lack of clear ownership semantics in APIs. If I call a function in your module which takes a Foo*, am I passing ownership? (So you’re responsible for freeing the object)? Do I need to retain the object while you use it? How long? Can I free the Foo when the function call returns? Or do you hold onto that reference until much later? Am I free to keep interacting with the Foo while you hold a reference? Can I do that from a separate thread, or is that unsafe? Every time I call a function in a medium to large C project (or in a library), I need to answer all these questions. Documentation is often unclear and the language doesn’t help at all. Mistakes lead to crashes, corruption and CVEs.
Real GC languages (Java, C#, JS, etc) solve this problem by just letting me write my code however I want. The object is freed when no more references are held. So I don’t even have to think about it. The cost is worse performance at runtime. Rust solves this with lifetimes and static analysis. You pay with complexity and slow compilation. But programs are fast and correct.
C - and by extension Fil-C - makes me solve this problem by hand. But you also pay a runtime performance cost to use a GC. This seems like the worst of all worlds.
Obviously people still write large programs in C. But I’d argue they manage that through grit and skill, in spite of C’s weak ownership semantics. Not because of it.