Fil-C: Garbage In, Memory Safety Out [video]

Post by quotemstr » Fri, Jul 24, 2026, 8:01 PM UTC

modeless wrote: post #10

wasmperson wrote: post #2

He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too. Someone i…

Rust doesn't runtime validate that your usage of syscalls is memory safe, while Fil-C does. For example you can call mmap in Fil-C and it is still guaranteed to be memory safe, while in Rust you can easily violate memory safety by calling mmap. This seems like an unambiguous improvement to me. This is as memory safe as it is possible to be on a system with a kernel that is not memory safe. Adding Fil-C-like runtime c…

Post by ratmice » Fri, Jul 24, 2026, 8:04 PM UTC

zem wrote: post #19

woodruffw wrote: post #16

Earlier quoted context omitted.

How would Rust perform static checks on dynamic bounds? That seems like an impossible order, i.e. not a reasonable evaluation criteria for any (general-purpose) language. (I'm separately skeptical that it's the most important memory safety property; I suspect that a review of Chrome and Firefox 0days would show that UAFs and type confusion are, at least to attackers, equally if not more important.)

ATS could probably do some of this by constructing proofs about the bounds and indices - not in the completely general case of course, but for at least some fraction of what a language without dependent types would have to defer to runtime

Post by yjftsjthsd-h » Fri, Jul 24, 2026, 8:12 PM UTC

cypherpunk666 wrote: post #3

wasmperson wrote: post #2

He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too. Someone i…

indeed, the ideas could be used more widely. fil-c runs on linux. what if linux ran on fil-c?

Post by minraws » Fri, Jul 24, 2026, 8:13 PM UTC

modeless wrote: post #10

wasmperson wrote: post #2

He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too. Someone i…

Rust doesn't runtime validate that your usage of syscalls is memory safe, while Fil-C does. For example you can call mmap in Fil-C and it is still guaranteed to be memory safe, while in Rust you can easily violate memory safety by calling mmap. This seems like an unambiguous improvement to me. This is as memory safe as it is possible to be on a system with a kernel that is not memory safe. Adding Fil-C-like runtime c…

Post by wasmperson » Fri, Jul 24, 2026, 8:19 PM UTC

uecker wrote: post #9

LoganDark wrote: post #4

Earlier 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.

  for i in some_arr {
    println!("{i}");
  }