> Is this website promoting Rust, memory unsafety and insecurity?
What a joke of a question. The website prioritizes programs with 98% safe code over programs with 0% safe code. Does that mean it's "promoting memory unsafety" because it's not demanding 100%? No.
> This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the capacity field because there's no way to verify it.
> Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
If 2% code means that, wildly spitballing, 50% code has to be manually reviewed, it's not quite as impressive.
And it might be worse regarding memory safety than the "status quo" if one accepts the assumption that unsafe Rust is harder than C and C++, as many Rust developers do.
> It may be even less safe because of the strong aliasing rules. That is, it may be harder to write correct unsafe {} Rust than correct C. Only use unsafe {} when absolutely needed.
If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code.
When I wrote "98% safe code" I meant the code that can be automatically verified by the compiler. I wish the terminology was better.
> If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand.
More or less correct, but in principle, it also requires modules to have proper encapsulation and interfaces. Otherwise, an interface could be made that enables safe API functions to cause memory unsafety if called incorrectly.
> "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code.
I mean, you have the search results right there. You could always take the time to look for yourself instead of "wildly spitballing", especially since the codebase is not that large.
Might want to take a closer look at your search results anyways, since those results include the FAQ, the sudoers man page, and instances of #![forbid(unsafe_code)] and #![deny(unsafe_code)]. Not exactly a promising start...
But since you asked so nicely, by tokei's count and my transcribing file paths, the modules including the `unsafe` keyword account for ~39% (8207/21106) of the total lines of code in the repo. I don't think you'll need to actually look at anywhere near that amount of code, though; from a brief glance through the search results I suspect most of the `unsafe` usages are for FFI calls, and relatively self-documenting/self-contained ones at that. If there were modules with module-wide invariants, I do not appear to have stumbled upon them.
> When I wrote "98% safe code" I meant the code that can be automatically verified by the compiler. I wish the terminology was better.
That depends on what is meant by "automatically verified by the compiler". The compiler cannot generally verify outside-unsafe code that modifies invariants that inside-unsafe code might rely on to have memory safety, for instance.
I mean the portion of the code that has no write access to those fragile invariants. At minimum, this includes all modules that don't have unsafe blocks.
> Is this website promoting Rust, memory unsafety and insecurity?
What a joke of a question. The website prioritizes programs with 98% safe code over programs with 0% safe code. Does that mean it's "promoting memory unsafety" because it's not demanding 100%? No.
> Nor is it guaranteed to be secure.
Nothing is, and nobody is claiming that.