5 ms·

> Almost all uses of unsafe in Rust are either for FFI Which makes Rust less safe than Fil-C. Consider that you have a dependency like libc, PAM, openssl, or

> Almost all uses of unsafe in Rust are either for FFI Which makes Rust less safe than Fil-C. Consider that you have a dependency like libc, PAM, openssl, or the like. In Rust: you will `unsafe` call into the unsafe versions of those libraries. Hence, even if your Rust code is safe in isolation, your program is not safe overall because you're pulling in unsafe code. In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe.

josephg 11mo ago
> In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe. Great work on Fil-C by the way. Very technically impressive stuff! It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#? If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). More and more C libraries are getting pure rust ports these days. It’s increasingly rare to actually need to pull in C libraries at all. Sticking to safe rust is a bit inconvenient - but I suspect so is using fil-c. I suppose with fil-C you can use any libraries you want, you’ve just gotta recompile them. That’s cool! Rust has a bunch of unsafe code in std, so you’re still at risk of a bug there causing safety problems. But the same is true of Fil-C. I could definitely see myself reaching for Fil-C when running legacy code. It’d be nice if there was a way to use fil-C to protect my rust program from memory bugs in C dependencies. But I can think of dozens of ways why that would be tricky to pull off. Also I’m curious - can Fil-C protect against threading bugs like rust can? Rust has Send & Sync traits to mark which objects can be safely shared between threads. I can’t think of a way to do that in an automated way without help from the programmer.
- drnick1 11mo ago
  > More and more C libraries are getting pure rust ports these days. I don't think these rewrites will ever be mainstream. There is so much C out there, and typically ports focus on the 90% that is easy to write and neglect the remaining 10%.
  - josephg 11mo ago
    > I don't think these rewrites will ever be mainstream. Forever is a long time. And there's always a huge appetite amongst smart young developers to create their own ecosystem. After all, you don't become Linus Torvalds by contributing to linux. You become linus torvalds by creating your own operating system from scratch. Whether or not new implementations become valuable and get maintained over time is an open question. But the energy is definitely there. (Even though its not necessarily pointed in the direction of economically useful, long lived software.) > typically ports focus on the 90% that is easy to write and neglect the remaining 10%. I hear a claim like: "The current C version of most tools is the only place, and only project which will ever bother solving its chosen problem properly." I'm not sure if tahts quite what you mean, but its a wildly bold claim. Even in C and C++, this seems already false. There's several good, solid, standards compliant SQL databases. And OS kernels. And compilers. And web browsers. If there's room for several C based OS kernels, do you really think there'll never be a viable OS kernel in rust, Zig or Odin? Or a web browser or compiler?
    - drnick1 11mo ago
      > And there's always a huge appetite amongst smart young developers to create their own ecosystem. After all, you don't become Linus Torvalds by contributing to linux. You become linus torvalds by creating your own operating system from scratch. The tech landscape was completely different back then. Linus himself stated that had BSD been free at the time, he wouldn't have started working on a free MINIX clone. He worked to solve a concrete problem (the lack of a free UNIX-like kernel), he didn't partially rewrite something that exists and works well just to "create his own ecosystem."
      - josephg 11mo ago
        Ok, that might be true of Linus himself. But I'm not sure what point you're making by bringing that up. Give up then? Linux forever, lets never try and iterate and improve? Its weird talking to people in this thread. I get the impression lots of folks would really like it if the actual C code making up linux stayed in place forever. Like it would be a good thing if humans exploring the cosmos in the year 3025 were still logging in using pam, written in C. And not just C, but the current lines of code we have right now. Why? Because! Because C is the best at things. Things like dynamic linking! Because don't change what works. Because if you rewrite something you might get bugs. Because C is fast and efficient. Oh, never mind fast and efficient - lets compile it with Fil-C even though it makes it really slow, just so long as we don't have to change the code! I think gnu/linux could be way better than it is now, in lots of ways. I get the impression that we - as a species - have barely scratched the surface of the design space for operating systems. The UNIX model is a really early design attempt. Is it the best design that will ever exist? Of course not. Do you know how the unix socket API came about? It was an intern / grad student at berkley who happened to be at the right place and right time. They invented an API and its basically never been changed since then. Because its the right API? No. Just because they were there and it was too hard to change it later. I want proper capabilities. I want a microkernel. I want faster syscalls. I want storage that's relational, not just file based. I want atomic disk operations. I want programs which can be migrated between computers while they're running. I want supervisor trees. I want data that can be moved or shared between computers. I want my programming languages which can talk to each other using something richer than the C ABI. I want debugging tools that work with lots of languages. I want to be able to download and run programs from the internet safely, without risking all my data. This is all technically possible today. But the idea of just making a bug for bug compatible, drop in replacement of a single tool like sudo is met with so much hostility and distrust from the community. Sometimes I think I live in a different world than most people. I think things can be better. I want things to be better. But we can't get there if we can't accept any change.
- pizlonator 11mo ago
  > It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#? Say you wanted to write a tool like sudo in C# or Go. Here's what would happen: you'd end up having to rely on dependent libraries, like pam, which then relies on other things like libselinux and libaudit. And libselinux depends on pcre2. Those things would be compiled with Yolo-C, so while your sudo tool's new code written by you would be safe, the process would mostly contain unsafe code. But if you write sudo in Fil-C, then you can rely on all of those dependencies being compiled with Fil-C. The whole process is safe. So, the reason why you'd pick Fil-C is that it's actually memory safe for real, unlike the alternatives, which just give you safety for newly written code but pull in a ton of unsafe depenendencies. > If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). That's impractical for the reasons above. > Also I’m curious - can Fil-C protect against threading bugs like rust can? Not like Rust can, but yes, it does. Fil-C preserves memory safety under races. This means that debugging multithreaded C/C++ programs in Fil-C is a much nicer experience than in Yolo-C. If you do something wrong, you're going to get a panic - similar to how multithreading bugs in Java or C# lead to exceptions. But, unlike Rust, Fil-C does not attempt to ensure race-freedom for your own logic.
  - josephg 11mo ago
    > the reason why you'd pick Fil-C is that it's actually memory safe for real, unlike the alternatives, which just give you safety for newly written code but pull in a ton of unsafe depenendencies. Right; that makes a lot of sense. So currently the only implementation of pam is written in Yolo-C. If you want to build a safe, secure tool which depends on pam - like sudo - then you either need to trust pam (like sudo-rs does). Or you need some way to compile pam to safe code. Fil-C is a way to do that. Just to name them - I can think of two other solutions to this problem: 1. Sandbox pam within a wasm container. This is probably less convenient than Fil-C (although it would allow that wasm container to be linked from yolo-c, rust, go, js, etc). For pam in particular, this would also be much less safe than Fil-C, since memory bugs in pam would still be possible, and might still result in privilege escalation. Wasm only sandboxes memory at the boundary. It wouldn't protect pam itself from its own bugs like Fil-C does. 2. Rewrite pam itself in a safer language, like C#, Go or Rust. Then sudo-rs doesn't need to link to yolo C code. I suspect someone will do this soon. I think this also reaffirms the role I see for Fil-C: as a tool to make legacy C code (like pam) safe, at the cost of performance. For new code, I'd rather pick a fully GC language if I don't care about performance, or use rust if performance matters. Again, it would be nice if I could have the best of both worlds - use fil-c to wrap and sandbox pam, but write the rest of my program in rust or C# or Go or something else that is already safe without needing to pay fil-c's cost. > But, unlike Rust, Fil-C does not attempt to ensure race-freedom for your own logic. It depends what you're doing, but this can be a pretty big deal. I suppose this puts Fil-C in about the same safety and performance camp as Go, Java and C#. Ie, it has some protections that rust is missing - like there aren't any unsafe blocks. And its missing some protections rust has - like better thread safety. The unique selling point is it works with existing C code, like old C libraries that we don't want to rewrite. Thanks for your work on it!
viraptor 11mo ago
> you will `unsafe` call into the unsafe versions of those libraries Maybe. There's rust version of libc and SSL already. On the other hand fil-c won't help with dependencies written in C++, Fortran, and lots of others. The "less safe" gets very context dependent.
- aw1621107 11mo ago
  > On the other hand fil-c won't help with dependencies written in C++, Fortran, and lots of others. IIRC Fil-C is already documented to work with C++. It's not immediately obvious to me that there are any fundamental reasons Fil-C wouldn't work for Fortran and "lots of others" as well; a fairly large chunk of its work is done via a pass on LLVM IR [0] so anything that compiles to LLVM could reap Fil-C's benefits with (probably?) relatively minor alterations to frontends. [0]: https://fil-c.org/compiler https://fil-c.org/compiler
  - pizlonator 11mo ago
    Yeah, putting Fortran through the Fil-C pipeline is just a matter of a handful of hacks in flang.

josephg 11mo ago

> In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe. Great work on Fil-C by the way. Very technically impressive stuff! It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#? If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). More and more C libraries are getting pure rust ports these days. It’s increasingly rare to actually need to pull in C libraries at all. Sticking to safe rust is a bit inconvenient - but I suspect so is using fil-c. I suppose with fil-C you can use any libraries you want, you’ve just gotta recompile them. That’s cool! Rust has a bunch of unsafe code in std, so you’re still at risk of a bug there causing safety problems. But the same is true of Fil-C. I could definitely see myself reaching for Fil-C when running legacy code. It’d be nice if there was a way to use fil-C to protect my rust program from memory bugs in C dependencies. But I can think of dozens of ways why that would be tricky to pull off. Also I’m curious - can Fil-C protect against threading bugs like rust can? Rust has Send & Sync traits to mark which objects can be safely shared between threads. I can’t think of a way to do that in an automated way without help from the programmer.

drnick1 11mo ago
> More and more C libraries are getting pure rust ports these days. I don't think these rewrites will ever be mainstream. There is so much C out there, and typically ports focus on the 90% that is easy to write and neglect the remaining 10%.
- josephg 11mo ago
  > I don't think these rewrites will ever be mainstream. Forever is a long time. And there's always a huge appetite amongst smart young developers to create their own ecosystem. After all, you don't become Linus Torvalds by contributing to linux. You become linus torvalds by creating your own operating system from scratch. Whether or not new implementations become valuable and get maintained over time is an open question. But the energy is definitely there. (Even though its not necessarily pointed in the direction of economically useful, long lived software.) > typically ports focus on the 90% that is easy to write and neglect the remaining 10%. I hear a claim like: "The current C version of most tools is the only place, and only project which will ever bother solving its chosen problem properly." I'm not sure if tahts quite what you mean, but its a wildly bold claim. Even in C and C++, this seems already false. There's several good, solid, standards compliant SQL databases. And OS kernels. And compilers. And web browsers. If there's room for several C based OS kernels, do you really think there'll never be a viable OS kernel in rust, Zig or Odin? Or a web browser or compiler?
  - drnick1 11mo ago
    > And there's always a huge appetite amongst smart young developers to create their own ecosystem. After all, you don't become Linus Torvalds by contributing to linux. You become linus torvalds by creating your own operating system from scratch. The tech landscape was completely different back then. Linus himself stated that had BSD been free at the time, he wouldn't have started working on a free MINIX clone. He worked to solve a concrete problem (the lack of a free UNIX-like kernel), he didn't partially rewrite something that exists and works well just to "create his own ecosystem."
    - josephg 11mo ago
      Ok, that might be true of Linus himself. But I'm not sure what point you're making by bringing that up. Give up then? Linux forever, lets never try and iterate and improve? Its weird talking to people in this thread. I get the impression lots of folks would really like it if the actual C code making up linux stayed in place forever. Like it would be a good thing if humans exploring the cosmos in the year 3025 were still logging in using pam, written in C. And not just C, but the current lines of code we have right now. Why? Because! Because C is the best at things. Things like dynamic linking! Because don't change what works. Because if you rewrite something you might get bugs. Because C is fast and efficient. Oh, never mind fast and efficient - lets compile it with Fil-C even though it makes it really slow, just so long as we don't have to change the code! I think gnu/linux could be way better than it is now, in lots of ways. I get the impression that we - as a species - have barely scratched the surface of the design space for operating systems. The UNIX model is a really early design attempt. Is it the best design that will ever exist? Of course not. Do you know how the unix socket API came about? It was an intern / grad student at berkley who happened to be at the right place and right time. They invented an API and its basically never been changed since then. Because its the right API? No. Just because they were there and it was too hard to change it later. I want proper capabilities. I want a microkernel. I want faster syscalls. I want storage that's relational, not just file based. I want atomic disk operations. I want programs which can be migrated between computers while they're running. I want supervisor trees. I want data that can be moved or shared between computers. I want my programming languages which can talk to each other using something richer than the C ABI. I want debugging tools that work with lots of languages. I want to be able to download and run programs from the internet safely, without risking all my data. This is all technically possible today. But the idea of just making a bug for bug compatible, drop in replacement of a single tool like sudo is met with so much hostility and distrust from the community. Sometimes I think I live in a different world than most people. I think things can be better. I want things to be better. But we can't get there if we can't accept any change.
pizlonator 11mo ago
> It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#? Say you wanted to write a tool like sudo in C# or Go. Here's what would happen: you'd end up having to rely on dependent libraries, like pam, which then relies on other things like libselinux and libaudit. And libselinux depends on pcre2. Those things would be compiled with Yolo-C, so while your sudo tool's new code written by you would be safe, the process would mostly contain unsafe code. But if you write sudo in Fil-C, then you can rely on all of those dependencies being compiled with Fil-C. The whole process is safe. So, the reason why you'd pick Fil-C is that it's actually memory safe for real, unlike the alternatives, which just give you safety for newly written code but pull in a ton of unsafe depenendencies. > If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). That's impractical for the reasons above. > Also I’m curious - can Fil-C protect against threading bugs like rust can? Not like Rust can, but yes, it does. Fil-C preserves memory safety under races. This means that debugging multithreaded C/C++ programs in Fil-C is a much nicer experience than in Yolo-C. If you do something wrong, you're going to get a panic - similar to how multithreading bugs in Java or C# lead to exceptions. But, unlike Rust, Fil-C does not attempt to ensure race-freedom for your own logic.
- josephg 11mo ago
  > the reason why you'd pick Fil-C is that it's actually memory safe for real, unlike the alternatives, which just give you safety for newly written code but pull in a ton of unsafe depenendencies. Right; that makes a lot of sense. So currently the only implementation of pam is written in Yolo-C. If you want to build a safe, secure tool which depends on pam - like sudo - then you either need to trust pam (like sudo-rs does). Or you need some way to compile pam to safe code. Fil-C is a way to do that. Just to name them - I can think of two other solutions to this problem: 1. Sandbox pam within a wasm container. This is probably less convenient than Fil-C (although it would allow that wasm container to be linked from yolo-c, rust, go, js, etc). For pam in particular, this would also be much less safe than Fil-C, since memory bugs in pam would still be possible, and might still result in privilege escalation. Wasm only sandboxes memory at the boundary. It wouldn't protect pam itself from its own bugs like Fil-C does. 2. Rewrite pam itself in a safer language, like C#, Go or Rust. Then sudo-rs doesn't need to link to yolo C code. I suspect someone will do this soon. I think this also reaffirms the role I see for Fil-C: as a tool to make legacy C code (like pam) safe, at the cost of performance. For new code, I'd rather pick a fully GC language if I don't care about performance, or use rust if performance matters. Again, it would be nice if I could have the best of both worlds - use fil-c to wrap and sandbox pam, but write the rest of my program in rust or C# or Go or something else that is already safe without needing to pay fil-c's cost. > But, unlike Rust, Fil-C does not attempt to ensure race-freedom for your own logic. It depends what you're doing, but this can be a pretty big deal. I suppose this puts Fil-C in about the same safety and performance camp as Go, Java and C#. Ie, it has some protections that rust is missing - like there aren't any unsafe blocks. And its missing some protections rust has - like better thread safety. The unique selling point is it works with existing C code, like old C libraries that we don't want to rewrite. Thanks for your work on it!

viraptor 11mo ago

> you will `unsafe` call into the unsafe versions of those libraries Maybe. There's rust version of libc and SSL already. On the other hand fil-c won't help with dependencies written in C++, Fortran, and lots of others. The "less safe" gets very context dependent.

aw1621107 11mo ago
> On the other hand fil-c won't help with dependencies written in C++, Fortran, and lots of others. IIRC Fil-C is already documented to work with C++. It's not immediately obvious to me that there are any fundamental reasons Fil-C wouldn't work for Fortran and "lots of others" as well; a fairly large chunk of its work is done via a pass on LLVM IR [0] so anything that compiles to LLVM could reap Fil-C's benefits with (probably?) relatively minor alterations to frontends. [0]: https://fil-c.org/compiler https://fil-c.org/compiler
- pizlonator 11mo ago
  Yeah, putting Fortran through the Fil-C pipeline is just a matter of a handful of hacks in flang.