HN

Comments (69)

• Menu

  mbrock
  I'm working on packaging Fil-C for Nix, as well as integrating Fil-C as a toolchain in Nix so you can build any Nix package with Fil-C.https://github.com/mbrock/filnixIt's working. It builds tmux, nethack, coreutils, Perl, Tcl, Lua, SQLite, and a bunch of other stuff.Binary cache on https://filc.cachix.org so you don't have to wait 40 minutes for the Clang fork to build.If you have Nix with flakes on a 64-bit Linux computer, you can run nix run github:mbrock/filnix#nethack right now!
• Menu

  kragen
  Either Fil-C or a different implementation of the same idea seems essential to me. A great deal of software has been written in C, and without some way of running it, we lose access to that intellectual heritage. But pervasive security vulnerabilities mean that the traditional "YOLO" approach to C compilation is a bad idea for software that has to handle untrusted input, such as Web browsing or email.Pizlo seems to have found an astonishingly cheap way to do the necessary pointer checking, which hopefully I will be able to understand after more study. (The part I'm still confused about is how InvisiCaps work with memcpy.)tialaramex points out that we shouldn't expect C programmers to be excited about Fil-C. The point tialaramex mentions is "DWIM", like, accessing random memory and executing in constant time, but I think most C programmers won't be willing to take a 4× performance hit. After all, if they wanted to be using a slow language, they wouldn't be writing their code in C. But I think that's the wrong place to look for interest: Fil-C's target audience is users of C programs, not authors of C programs. We want the benefits of security and continued usage of existing working codebases, without having to pay the cost to rewrite everything in Rust or TypeScript or whatever. And for many of us, much of the time, the performance hit may be acceptable.
• cjk
  I worked with the author of Fil-C at Apple while on the Safari team, and he's easily one of the brightest folks I've had the pleasure of knowing. Fil-C looks extremely cool.
• gnabgib
  No discussion, but just on the front page last week (31 points) https://news.ycombinator.com/item?id=45655519Previous discussion:2025 Safepoints and Fil-C (87 points, 1 month ago, 44 comments) https://news.ycombinator.com/item?id=452580292025 Fil's Unbelievable Garbage Collector (603 points, 2 months ago, 281 comments) https://news.ycombinator.com/item?id=451339382024 The Fil-C Manifesto: Garbage In, Memory Safety Out (13 points, 17 comments) https://news.ycombinator.com/item?id=39449500
• Menu

  ridiculous_fish
  Extraordinary project. I had several questions which I believe I have answered for myself (pizlonator please correct if wrong):1. How do we prevent loading a bogus lower through misaligned store or load?Answer: Misaligned pointer load/stores are trapped; this is simply not allowed.2. How are pointer stores through a pointer implemented (e.g. `*(char **)p = s`) - does the runtime have to check if *p is "flight" or "heap" to know where to store the lower?Answer: no. Flight (i.e. local) pointers whose address is taken are not literally implemented as two adjacent words; rather the call frame is allocated with the same object layout as a heap object. The flight pointer is its "intval" and its paired "lower" is at the same offset in the "aux" allocation (presumably also allocated as part of the frame?).3. How are use-after-return errors prevented? Say I store a local pointer in a global variable and then return. Later, I call a new function which overwrites the original frame - can't I get a bogus `lower` this way?Answer: no. Call frames are allocated by the GC, not the usual C stack. The global reference will keep the call frame alive.That leads to the following program, which definitely should not work, and yet does. ~Amazing~ Unbelievable: #include <stdio.h> char *bottles[100]; __attribute__((noinline)) void beer(int count) { char buf[64]; sprintf(buf, "%d bottles of beer on the wall", count); bottles[count] = buf; } int main(void) { for (int i=0; i < 100; i++) beer(i); for (int i=99; i >= 0; i--) puts(bottles[i]); }
• nextaccountic
  Somewhat related, safe C++ proposal is not being continuedhttps://news.ycombinator.com/item?id=45234460
• Menu

  Panzerschrek
  Great effort, but I find the whole idea somewhat flawed. If one needs speed, he can't use this C implementation, because it's several times slower. If speed isn't important, why not just using a memory safe language? And if both are important, why not using Rust?Recompiling existing software written in C using Fil-C isn't also a great idea, since some modifications are likely needed, at least for fixing bugs found with usage of Fil-C. And after these bugs are fixed, why continue using Fil-C?
• Menu

  synergy20
  posted multiple times, x86 only last time I checked
• EverydayBalloon
  [dead]
• Menu

  dmitrygr
  TLDR: 4x slowdown in the normal casethe performance overhead of this approach for most programs makes them run about four times more slowly
• Menu

  braggerxyz
  Every time I read C and memory safety, I just think Golang. Especially for user space