Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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

    by jitl
  • I would really like to see Omarchy go this direction. A fully memory-safe userland for Omarchy is possible with existing techhnology.
  • Can you elaborate why Omarchy? I'm asking, in context of recompiling with Fil-C, because that seems to be just Arch + configurations.
  • I’m glad Phil’s work is finally getting the recognition it deserves.

    There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

  • > particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

    As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.

    by gpm
  • 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 - Sept 2025 (2 comments)

    Just some of the memory safety errors caught by Fil-C - https://news.ycombinator.com/item?id=43215935 - March 2025 (5 comments)

    The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=42226587 - Nov 2024 (1 comment)

    Rust haters, unite Fil-C aims to Make C Great Again - https://news.ycombinator.com/item?id=42219923 - Nov 2024 (6 comments)

    Fil-C a memory-safe version of C and C++ - https://news.ycombinator.com/item?id=42158112 - Nov 2024 (1 comment)

    Fil-C: Memory-Safe and Compatible C/C++ with No Unsafe Escape Hatches - https://news.ycombinator.com/item?id=41936980 - Oct 2024 (4 comments)

    The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=39449500 - Feb 2024 (17 comments)

    In addition, here are the major related subthreads from other submissions:

    https://news.ycombinator.com/item?id=45568231 (Oct 2025)

    https://news.ycombinator.com/item?id=45444224 (Oct 2025)

    https://news.ycombinator.com/item?id=45235615 (Sept 2025)

    https://news.ycombinator.com/item?id=45087632 (Aug 2025)

    https://news.ycombinator.com/item?id=44874034 (Aug 2025)

    https://news.ycombinator.com/item?id=43979112 (May 2025)

    https://news.ycombinator.com/item?id=43948014 (May 2025)

    https://news.ycombinator.com/item?id=43353602 (March 2025)

    https://news.ycombinator.com/item?id=43195623 (Feb 2025)

    https://news.ycombinator.com/item?id=43188375 (Feb 2025)

    https://news.ycombinator.com/item?id=41899627 (Oct 2024)

    https://news.ycombinator.com/item?id=41382026 (Aug 2024)

    https://news.ycombinator.com/item?id=40556083 (June 2024)

    https://news.ycombinator.com/item?id=39681774 (March 2024)

    https://news.ycombinator.com/item?id=39542944 (Feb 2024)

    by dang
  • Thanks for the subthread discussion links, e.g. authors of LuaJIT and Fil-C, https://news.ycombinator.com/item?id=40556083 (June 2024)
  • 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.
  • Can a program be written only partially in Fil-C? That is to say, can we link regular C and Fil+C object files in a single executable?
  • > There is no interoperability with Yolo-C (i.e. classic C). This is both a goal and the outcome of a non goal.

    https://fil-c.org/runtime

    (worth reading, i think all the stuff Fil writes is both super informative & quite entertaining.)

    by jitl
  • 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 checked. Fil-C has no unsafe statement and only limited FFI to unsafe code.

    https://fil-c.org/

    The posted article has a detailed explanation of djb successfully compiling a bunch of C and C++ codebases.

  • 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?
  • 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?

  • Filip of Fil-C is at Epic. Epic owns the copyright.
  • 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.

  • 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

  • by loeg
  • Use of pqconnect at yp.to is probably old news but the cdb.cr.yp.to CNAME does appear to be new as of around 21 Oct

    The notes on using Fil-C were submitted three days ago

    https://news.ycombinator.com/item?id=45765718

  • The PQConnect documentation, specifically the document "INSTALL.md", describes the pq1 portion of the CNAME as a subdomain.

       Please update your DNS A/AAAA records for all domains on this server as follows:
    
       Existing record:
       Type    Name        Value
       A/AAAA  SUBDOMAIN   IP Address
    
       New Records:
       Type    Name        Value
       CNAME   SUBDOMAIN   pq1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.DOMAIN.TLD
       A/AAAA  pq1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  IP Address
       TXT    pq1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.DOMAIN.TLD    p=42424
       TXT    ks.pq1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.DOMAIN.TLD    ip=IP ADDRESS;p=42425"
  • RFC 1034 Domain Concepts and Facilities November 1987 [Page 8]

    "A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " "."

       1 cdb.cr.yp.to - regular DNS:
       124 bytes, 1+2+0+0 records, response, noerror
       query: 1 cdb.cr.yp.to
       answer: cdb.cr.yp.to 30 CNAME pq1jbw2qzb2201xj6pyx177b8frqltf7t4wdpp32fhk0w3h70uytq5020w020l0.yp.to
       answer: pq1jbw2qzb2201xj6pyx177b8frqltf7t4wdpp32fhk0w3h70uytq5020w020l0.yp.to 30 A 131.193.32.109
    
    In the terminology of RFC1034, cdb.cr.yp.to, a CNAME, can be described as a subdomain of cr.yp.to and yp.to

    (NB. The pq1 portion is not a public key, it is a hash of a server's long-term public key)

  • > Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve

    This is not correct. There isn't a cdb subdomain because cdb.cr.yp.to doesn't have NS records, which is where DNSCurve fits in. If you have a DNSCurve resolver, then your queries for cdb.cr.yp.to will use DNSCurve and will be sent to the yp.to nameservers.

    From there, if you have pqconnect, your http(s) connection to cdb.cr.yp.to will happen over pqconnect.

    Maybe the confusion is because both DNSCurve and pqconnect encode pubkeys in DNS, but they do different things.

    Here is DNSCurve:

      $ dig +short ns yp.to
      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
    
    Here is pqconnect:

      $ dig +short cdb.cr.yp.to
      pq1htvv9k4wkfcmpx6rufjlt1qrr4mnv0dzygx5mlrjdfsxczbnzun055g15fg1.yp.to.
      131.193.32.108
    
    Like CurveCP, pqconnect puts the pubkey into a CNAME.
  • > I had originally configured the server phoenix with only 12GB swap. I then had to restart ./build_all_fast_glibc.sh a few times because the Fil-C compilation ran out of memory. Switching to 36GB swap made everything work with no restarts; monitoring showed that almost 19GB swap (plus 12GB RAM) was used at one point. A larger server, 128 cores with 512GB RAM, took 8 minutes for Fil-C plus 6 minutes for musl, with no restarts needed.

    Yikes that’s a lot of memory! Filc is doing a lot of static analysis apparently.

  • I think that's the build of LLVM+Clang itself.
  • To summarize, he's sufficiently impressed with it that he's embarking on an attempt to rebuild an entire Debian system with it, and he's written some software (a GC shim library and build scripts) that are likely to be of interest to others who are attempting the same thing.