4 ms·

Rust is less safe because it has a feature for turning off safety, called `unsafe`. Fil-C does not have a way to turn off safety, and it enforces safety checks

by jitl 2mo ago

Rust is less safe because it has a feature for turning off safety, called `unsafe`. Fil-C does not have a way to turn off safety, and it enforces safety checks at runtime. That's the reasoning anyways. If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.

MaulingMonkey 2mo ago
> If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C. Just write `#![forbid(unsafe_code)]` at the top of your src/lib.rs, and track crates not using it with `cargo geiger`. You don't need a whole new language, it already provides the tools to wield that hatch shut. > Rust is less safe because it has a feature for turning off safety Can I write Fil-C's mmap wrapper in Fil-C? If no, fair enough, but it's worth noting I can write a safe Rust mmap wrapper in Rust, and I absolutely and frequently need to do that kind of "syscall wrapping" in arenas Fil-C explicitly hasn't handled, by virtue of being explicitly a Linux project. If yes, that sounds like an escape hatch to Fil-C's memory safety, undermining the claim that Fil-C is fundamentally safer, and you're now at best arguing it's safer as tends to be used.
- im3w1l 2mo ago
  It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.
  - kibwen 2mo ago
    Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates its ability to realistically eliminate memory safety risks.
    - im3w1l 2mo ago
      A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.
      - kibwen 2mo ago
        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_in_memory_safety_out_filip_pizlo_ssw/ozil7lz/ https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...
        MaulingMonkey 2mo ago
        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-even-safe-rust-didn-t-save-us 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 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://github.com/orgs/rust-lang/projects/44/views/1 • https://rust-lang.github.io/rust-project-goals/2025h2/next-solver.html 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.
        2mo ago
Cyph0n 2mo ago
But the runtime cost of Fil-C means that - in most cases - your actual production application will be compiled with a standard C compiler. This applies not just to your code, but to all dependencies (due to ABI). So I don’t see how Rust is at a huge disadvantage here when Fil-C is typically not going to be enforcing safety in production. I suppose the testing/fuzzing story becomes all the more important because you need to exercise runtime behavior for Fil-C to detect unsafe faults. Don’t get me wrong: I think Fil-C is a smart idea and an excellent way to introduce memory safety to existing C codebases. But I don’t get this whole (usually implied) idea that Fil-C somehow makes Rust look bad or renders it obsolete.
- modeless 2mo ago
  The whole point of Fil-C is that it is fast enough to consider using in production for some applications while still guaranteeing memory safety. We already have ASAN and Valgrind and other tools for development purposes, that's not what Fil-C is targeting.
  - Cyph0n 2mo ago
    I am assuming that Fil-C introduces orders of magnitude less overhead than ASAN or Valgrind. Also, it’s probably fast enough for apps to be deployed in something like a staging environment for integration tests to run against them. Production deploy/release can then happen using a tagged version that gets compiled using vanilla GCC/Clang.
    - modeless 2mo ago
      I'm not sure about the speed of ASAN, it may be comparable but doesn't guarantee memory safety. It's only for catching mistakes and not secure against an adversary. Valgrind is dramatically slower.
  - josephg 2mo ago
    So Fil-C is competing with Go, C#, typescript and Python. If I’m writing a greenfield project where “bare metal” performance isn’t needed, why would anyone choose Fil-C over a more mature GC language? C is more verbose and more error prone than Go and C#. It has worse tooling. It’s missing decades of language features. C isn’t properly cross platform. There’s no package manager. The “standard library” isn’t fully standard. It’s full of sharp edges and bad decisions. I can imagine using Fil-C to run legacy code. But for new projects, it just seems worse in every way compared to Go, C#, typescript and friends. It’s worse, slow, and inconvenient.

by jitl 2mo ago

MaulingMonkey 2mo ago

> If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C. Just write `#![forbid(unsafe_code)]` at the top of your src/lib.rs, and track crates not using it with `cargo geiger`. You don't need a whole new language, it already provides the tools to wield that hatch shut. > Rust is less safe because it has a feature for turning off safety Can I write Fil-C's mmap wrapper in Fil-C? If no, fair enough, but it's worth noting I can write a safe Rust mmap wrapper in Rust, and I absolutely and frequently need to do that kind of "syscall wrapping" in arenas Fil-C explicitly hasn't handled, by virtue of being explicitly a Linux project. If yes, that sounds like an escape hatch to Fil-C's memory safety, undermining the claim that Fil-C is fundamentally safer, and you're now at best arguing it's safer as tends to be used.

im3w1l 2mo ago
It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.
- kibwen 2mo ago
  Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates its ability to realistically eliminate memory safety risks.
  - im3w1l 2mo ago
    A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.
    - kibwen 2mo ago
      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_in_memory_safety_out_filip_pizlo_ssw/ozil7lz/ https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...
      - MaulingMonkey 2mo ago
        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-even-safe-rust-didn-t-save-us 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 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://github.com/orgs/rust-lang/projects/44/views/1 • https://rust-lang.github.io/rust-project-goals/2025h2/next-solver.html 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.
        2mo ago

Cyph0n 2mo ago

But the runtime cost of Fil-C means that - in most cases - your actual production application will be compiled with a standard C compiler. This applies not just to your code, but to all dependencies (due to ABI). So I don’t see how Rust is at a huge disadvantage here when Fil-C is typically not going to be enforcing safety in production. I suppose the testing/fuzzing story becomes all the more important because you need to exercise runtime behavior for Fil-C to detect unsafe faults. Don’t get me wrong: I think Fil-C is a smart idea and an excellent way to introduce memory safety to existing C codebases. But I don’t get this whole (usually implied) idea that Fil-C somehow makes Rust look bad or renders it obsolete.

modeless 2mo ago
The whole point of Fil-C is that it is fast enough to consider using in production for some applications while still guaranteeing memory safety. We already have ASAN and Valgrind and other tools for development purposes, that's not what Fil-C is targeting.
- Cyph0n 2mo ago
  I am assuming that Fil-C introduces orders of magnitude less overhead than ASAN or Valgrind. Also, it’s probably fast enough for apps to be deployed in something like a staging environment for integration tests to run against them. Production deploy/release can then happen using a tagged version that gets compiled using vanilla GCC/Clang.
  - modeless 2mo ago
    I'm not sure about the speed of ASAN, it may be comparable but doesn't guarantee memory safety. It's only for catching mistakes and not secure against an adversary. Valgrind is dramatically slower.
- josephg 2mo ago
  So Fil-C is competing with Go, C#, typescript and Python. If I’m writing a greenfield project where “bare metal” performance isn’t needed, why would anyone choose Fil-C over a more mature GC language? C is more verbose and more error prone than Go and C#. It has worse tooling. It’s missing decades of language features. C isn’t properly cross platform. There’s no package manager. The “standard library” isn’t fully standard. It’s full of sharp edges and bad decisions. I can imagine using Fil-C to run legacy code. But for new projects, it just seems worse in every way compared to Go, C#, typescript and friends. It’s worse, slow, and inconvenient.