First, in a philosophical sense: pointers and x86 CPUs are real, ultimately any safe abstraction must be built on unsafe primitives. The ability and need to do that aren't specific to memory unsafety, we do that all over software engineering.
Second, empirically, my experience has been that the design of these abstractions can be safe, but moreover that the cordoning off of unsafe blocks makes 3p auditing for memory unsafety _much_ easier to do. It can be orders of magnitude faster than reviewing an entire C or C++ codebase.
A TCB should be dozens of lines, not thousands. More code means more places for more bugs to hide.
My experience in Safe Haskell was that, if you have to ask each module individually whether it has a safety property, then you've already created too much work for yourself. Instead, require every module to structurally encode the desired invariant.
Or, in fewer words: If you want memory safety, don't have `unsafe` blocks.
OCaml has its fair share of unsafe features, with the functions helpfully prefixed by "unsafe_". If you look through the stdlib you'll find dozens of such functions. Plus real world code uses them to do things like avoiding bounds checks. Much as I'm a fan of OCaml, even a pure OCaml implementation could do unsafe things.
Especially given that this is not a full rewrite from scratch - it follows more the model that Firefox uses: integrate components written in rust into an existing C code base. Rusts binding friendliness from and towards C will be a major point in such an effort.
A language like OCaml can still have memory unsafety issues introduced by the compiler or standard library. It just makes it much more manageable to effectively audit for and fix such issues. `unsafe` blocks serve the same purpose.
Not only that, but to write anything more than a hello world requires lots of unsafe blocks. There are loads of them everywhere, in all of those crates, incl. the standard library.
Moderately low-level crates require some unsafe blocks. Rust is supposed to be a systems language from what I heard, so if you are going to write something larger, and/or complicated, and/or low-level, you will have to resort to unsafe blocks, I think.
Yep, there are indeed loads of them. Feel free to clone all of those repositories and look for those unsafe blocks. You could even get it per-crate.
Of course there are some false positives in there, and yes, some crates may not have unsafe blocks (so not all crates have them, you got me), but still... It is a bit too many unsafe blocks.
Or I do not know, maybe they just have a thing for unsafe blocks, for example in the standard library (std) you can find 2267 unsafe blocks.
One thing to bear in mind is that the libc and winapi crates are bindings to the libc and Windows C headers, so every single function signature in there will be marked unsafe because it's FFI, so those will be heavily impacting your results.
You could also avoid some false positives in comments by searching for "unsafe fn" and "unsafe {", rather than just the word "unsafe", as those are the only tokens (to my knowledge) that can follow "unsafe".
