queejjd

> There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction.

If all of the Vec has to be "audited", or checked and reviewed, including all the code that is not inside unsafe blocks, how would the surface be any smaller?

> The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there.

Isn't it normal for programming languages to support building abstractions that can help with not only memory safety, but general correctness? C is a bit barebones, but lots of other programming languages, like C#, C++, Haskell and Scala support building abstractions that are harder to misuse.

What features do you like the most in Rust? Are pattern matching and enums some of them?

If a logic bug inside Vec and outside any unsafe blocks inside Vec happens, and that logic bug violates any invariants and requirements of the unsafe blocks, that can cause memory unsafety.

Two questions:

Why was the fix to this unsafe memory safety bug [0] only changes to code outside of unsafe Rust blocks?[1][2]

Why does the Rustonomicon[3] say the following?

> 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.

[0] https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

[3] https://doc.rust-lang.org/nomicon/working-with-unsafe.html