Yes, although there are other advantages to using Rust (about halfway down there's a "What does Rust offer here?" section that discusses in more detail).
Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety.
Also, if I were taking this more seriously, the wildly unsafe Rust code would just be a beach head for a bottom-up conversion of a project. You have a project which uses strlen? Great, now use this Rust version. Now incrementally rewrite the strlen-using code in Rust. Now change strlen to use a Rust CString...and so on. Each time you identify a new module boundary, rewrite its dependencies in Rust, and then consume the module while preserving it's outward facing interfaces.
> Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety.
That's kind of what I'm getting at. If cstdlib is inherently unsafe, and Rust cstdlib is going to be inherently unsafe, what's the point? Because of some other Rust advantages things may end up safer, but there's a lot to be said for years/decades worth of fixing existing cstdlib implementations such that you can be reasonably sure that most of what's in there is as safe as it's going to get.
The interface will have to be `unsafe`, yes (that is, there are conditions that the code calling the functions must satisfy to avoid memory unsafety), but the internals can control this unsafety and avoid having more: libc's have vulnerabilities that are not caused by their inherently unsafe interface.
The power of Rust is the ability to package up `unsafe`ty behind safe interfaces without adding unnecessary cost, so that most users don't have to be super-careful about avoiding memory corruption. This still works at a low-level like in the implementation of a libc or an operating system[1].
Also, Rust is a more expressive language, which helps avoid bugs (e.g. enums/discriminated unions means the programmer can't accidentally access invalid state), allows writing shared algorithms and data structures efficiently once instead of needing to do the bug-prone task of reimplementing (or taking a performance/safety hit with void*), and, subjectively, may be nicer to read/write .
Security and safety isn't a binary relation, it is a continuum.
I think what you are experiencing is a transitive-covering fallacy. The safeties with which you are speaking aren't the same type or the same units. The argument you making is often made by people on security discussion lists to _prove_ that modifying X to make it more secure is pointless because there is still a small possibility of Y.
> years/decades
How long has MUSL been in development? How many programmers there are in the world?
Frankly, the POSIX C standard library does not seem to have been designed with safety in mind (I don't think this requires an expert eye to see). So writing it in Rust is going to require a number of compromises on Rust's safety.
Also, if I were taking this more seriously, the wildly unsafe Rust code would just be a beach head for a bottom-up conversion of a project. You have a project which uses strlen? Great, now use this Rust version. Now incrementally rewrite the strlen-using code in Rust. Now change strlen to use a Rust CString...and so on. Each time you identify a new module boundary, rewrite its dependencies in Rust, and then consume the module while preserving it's outward facing interfaces.