7 ms·

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 com

• gnabgib 6mo 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 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 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 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 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 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 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 https://news.ycombinator.com/item?id=45133938
• pizlonator 6mo 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 6mo 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 6mo 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 https://fil-c.org/how
      • masfuerte 6mo ago
        Thanks, I did confuse you for the author of the article. Your InvisiCaps explanation is clearer than this "simplified" one.
• kbolino 6mo 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 6mo ago
    > it slows programs down Interesting, how costly would be hardware acceleration support for Fil-C code.
    • kbolino 6mo 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_RISC_Instructions https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... [2]: https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc
      • Findecanor 6mo ago
        There are algorithms to align allocations and use metadata in unused pointer bits to encode object start addresses. That would allow Fil-C's shadow memory to be reduced to a tag bit per 8-byte word (like 32-bit CHERI), at the expense of more bit shuffling. But that shuffling could certainly be a candidate for hardware acceleration. There is a startup working on "Object Memory Addressing" (OMA) with tracing GC in hardware [1], and its model seems to map quite well to Fil-C's. I have also seen a discussion on RISC-V's "sig-j" mailing list about possible hardware support for ZGC's pointer colours in upper pointer bits, so that it wouldn't have to occupy virtual memory bits — and space — for those. However, I think that tagged pointers with reference counting GC could be a better choice for hardware acceleration than tracing GC. The biggest performance bottleneck with RC in software are the many atomic counter updates, and I think those could instead be done transparently in parallel by a dedicated hardware unit. Cycles would still have to be reclaimed by tracing but modern RC algorithms typically need to trace only small subsets of the object graph. [1]: "Two Paths to Memory Safety: CHERI and OMA" https://news.ycombinator.com/item?id=45566660 https://news.ycombinator.com/item?id=45566660
• rvz 6mo 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.
  • uecker 6mo ago
    Even without Fil-C I do not think it is even clear that new software should be written in Rust. It seems to have a lot of fans, but IMHO it is overrated. If you need perfect memory safety Rust has an advantage at the moment, but if you are not careful you trade this for much higher supply chain risks. And I believe the advantage in memory safety will disappear in the next years due to improved tooling in C, simply by adding the formal verification that proves the safety which will work automatically.
    • kobebrookskC3 6mo ago
      > simply by adding the formal verification that proves the safety which will work automatically "simply" and "formal verification" are usually oxymorons, never mind "automatically"
      • uecker 6mo ago
        Fair enough, but I have seen how it works and for just temporal memory safety, it could be simple.
    • zozbot234 6mo ago
      Memory safety is absolute table stakes when it comes to formal verification. You can't endow your code with meaningful semantics if you don't have some way of ensuring memory safety.
      • uecker 6mo ago
        Indeed, and this is why people who care about this are also proving memory safety in C. The issue is that we do not have good open-source tooling that specifically focuses on formal verification of memory safety in C.
• dataflow 6mo 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 6mo 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 6mo 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.
      • FuckButtons 6mo ago
        I’m also a C++ programmer, I can’t even use half of the C++ stdlib for real time thread work, I certainly can’t use a GC.
        • pizlonator 6mo ago
          There are many C++ programmers and we are not the same! My original foray into GCs was making real time ones, and the Fil-C GC is based on that work. I haven’t fully made it real time friendly (the few locks it has aren’t RT-friendly) but if I had more time I could make it give you hard guarantees. It’s already full concurrent and on the fly, so it won’t pause you
        • cxr 6mo ago
          ∃ ≠ ∀
      • deleted 6mo ago
        [deleted]
    • 6mo ago
• GaggiX 6mo 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.
• omcnoe 6mo 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 6mo ago
    For some things the just-crash is ok, like cli usage of curl
  • pizlonator 6mo 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 6mo 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.
      • wakawaka28 6mo ago
        I don't think runtime error handling is impossible in Fil-C, at least in theory. But the use cases for that are fairly limited. Most errors like this are not anticipated, and if you did encounter them then there's little or nothing you can do useful in response. Furthermore, runtime handling to continue means code changes, thus coupling to the runtime environment. All of these things are bad. It is usually acceptable to fail fast and restart, or at least report the error.
• tialaramex 6mo 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 6mo 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.
    • achierius 6mo ago
      I can tell you that it's not that he's setting aside speed -- the fact that it's as fast as it is is an achievement. But there is a degree of unavoidable overhead -- IIRC his goal is to get it down to 20-30% for most workloads, but beyond that you're running into the realities of runtime bounds checks, materializing the flight ptrs, etc.
      • gmueckl 6mo ago
        20% to 30% slower would be amazing for all the extra runtime work that is required in my limited understanding. This would be good enough for a whole lot of serious applications.
• DetroitThrow 6mo 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 6mo ago
    Tell me more about Ada!
• adamnemecek 6mo ago
  It really doesn't, Rust is a better language.
• Panzerschrek 6mo ago
  Fil-C is only good if one needs to recompile an existing C program and gain extra safety without caring much about result performance. And even in such case I doubt it's useful, since existing code should be already well-tested and (almost) bug-free. If new code needs to be written, there is no reason to use Fil-C, since better languages with build-in security mechanisms exist.
  • ekaryotic 6mo ago
    could you recompile a c program in fil-c and then decompile it to c and recompile it in c to have the high performance.
    • aw1621107 6mo ago
      The performance hit comes from the extra work Fil-C does over regular C, so if your decompilation/recompiliation process preserves semantics that extra work (and thus the performance hit) will remain in the final product.
• krackers 6mo ago
  I don't think fil-c is a drop in C replacement, there are things you can do in C such as certain types of pointer abuse that fil-c prohibits (e.g. cast pointer to int, then back). It's probably easier to port an existing C project to Fil-C than to rewrite it entirely though.