3 ms·

Definitely not. Then it wouldn’t be a C implementation. Fil-C is so compatible that I have a Linux userland compiled with it https://fil-c.org/pizlix https://f

Definitely not. Then it wouldn’t be a C implementation. Fil-C is so compatible that I have a Linux userland compiled with it https://fil-c.org/pizlix https://fil-c.org/pizlix Think of Fil-C as Java-ifying C an C++

adastra22 1y ago
I don’t see the relevance to this discussion then.
- NobodyNada 1y ago
  The discussion is about a project for securing legacy code by machine-translating it to Rust. Fil-C is an alternative way to secure legacy code using a different C implementation. I think that's highly relevant to the discussion.
  - adastra22 1y ago
    The kind of errors being protected against are totally different though.
    - pizlonator 1y ago
      Fil-C protects against a superset of the errors that Rust protects against. It just does it dynamically. And more comprehensively. There’s no `unsafe` statement in Fil-C. There’s no need for it since dynamic checking is vastly more precise.
      - adastra22 1y ago
        Dynamic/runtime checks (and crashes) are VERY different from compile time checks though. Many applications, and especially those that DARPA are focused on, care about ahead-of-time guarantees that code will work correctly, and runtime panic is actually the worst possible failure mode. Think of flight control software, for example.
        pizlonator 1y ago
        This DARPA doc isn’t about flight software. Rust uses runtime checking for array access bounds, which are the most common kind of memory safety vulnerability.
      - jandrewrogers 1y ago
        Checking at compile-time is required for some applications and highly desirable regardless. This is something recent versions of C++ do really well. It is my main reason for using C++ beyond its unparalleled performance in practice.
- pizlonator 1y ago
  You’re confusing memory safety with Rust’s specific flavor of static checking. Totally not the same thing. Like, notice how DARPA is in no hurry to have folks rewrite Java or JavaScript in Rust. Why? Because even JavaScript is memory safe. It’s not achieving that with dynamic checking rather than static checking.

adastra22 1y ago

I don’t see the relevance to this discussion then.

NobodyNada 1y ago
The discussion is about a project for securing legacy code by machine-translating it to Rust. Fil-C is an alternative way to secure legacy code using a different C implementation. I think that's highly relevant to the discussion.
- adastra22 1y ago
  The kind of errors being protected against are totally different though.
  - pizlonator 1y ago
    Fil-C protects against a superset of the errors that Rust protects against. It just does it dynamically. And more comprehensively. There’s no `unsafe` statement in Fil-C. There’s no need for it since dynamic checking is vastly more precise.
    - adastra22 1y ago
      Dynamic/runtime checks (and crashes) are VERY different from compile time checks though. Many applications, and especially those that DARPA are focused on, care about ahead-of-time guarantees that code will work correctly, and runtime panic is actually the worst possible failure mode. Think of flight control software, for example.
      - pizlonator 1y ago
        This DARPA doc isn’t about flight software. Rust uses runtime checking for array access bounds, which are the most common kind of memory safety vulnerability.
    - jandrewrogers 1y ago
      Checking at compile-time is required for some applications and highly desirable regardless. This is something recent versions of C++ do really well. It is my main reason for using C++ beyond its unparalleled performance in practice.
pizlonator 1y ago
You’re confusing memory safety with Rust’s specific flavor of static checking. Totally not the same thing. Like, notice how DARPA is in no hurry to have folks rewrite Java or JavaScript in Rust. Why? Because even JavaScript is memory safe. It’s not achieving that with dynamic checking rather than static checking.