Why is libc used?

[michaelCTS]

I have no experience with developing such binaries so please excuse the ignorance. It looks like the usage of libc introduces unsafe code blocks in the rust code. If I'm not mistaken, it also introduces a dependency on libc, meaning the correction version has to be present in order for coreutils to run (different versions might make lead to crash).

RedoxOS developers have an incomplete rewrite of libc (relibc), but is libc absolutely necessary? Is libc a shortcut to the implementation of certain features too complicated to implement in rust? Is rewriting those parts of libc out of scope of the project?

[tertsdiepraam]

Oh good question! You're gonna get a long answer 😄

We have to do syscalls somewhere, which means that somewhere in our dependency tree, there's unsafe. Either we use unsafe ourselves or we let some library do it for us. libc is used throughout the Rust ecosystem, even in the standard library. This also means that we are always using libc indirectly through std already. It is usually the recommended way to deal with low-level stuff, because libc standardizes behaviour across many platforms. However, that doesn't mean that we're stuck with libc! We want to use as many safe abstractions over libc as possible. The nix crate, for example, provides safe APIs over libc. We also (indirectly) use rustix (a libc alternative). We could use relibc, but it only supports Linux and Redox at the moment.

Developing a libc alternative is definitely out of scope for this project, but we try to help out a bit with some of the projects I've mentioned when we need them.

Also note that unsafe for FFI is the most acceptable form of unsafe. Many of those APIs have no way they can cause unsound behaviour, it's just that the type system doesn't know about them. Still, using safe alternatives would of course be preferable.

[michaelCTS]

Thank you! That's the detail I was looking for 👍