[bitwize]

Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.

[uecker]

IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to find as a keyword, but I do not think this is a fundamental advantage, especially in projects where you have a lot of such "unsafe" blocks.

[Xylakant]

> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust.

That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.

[uecker]

First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement.

Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again.

Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.

[unrealhoang]

> logic bugs outside "unsafe" can cause bugs unsafe.

This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build.

The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".

[queejjd]

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

[queejjd]

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.

[unrealhoang]

That would be the unsoundness of `Vec` itself, but if the abstraction of `Vec` is sound, there would be no way to use `Vec` outside of `unsafe` that can cause memory unsafety.

The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there. 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. Also, when soundness bug appears, the responsibility is solely on the abstraction writer, not the user.

Whereas in C, without those safe abstraction, the surface of doing thing right to avoid memory safety issue is your entire codebase, and responsibility of "holding the knife correctly" is on the user.

[wmanley]

> in C only specific language features are unsafe and not all code

Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without:

* Dereferencing pointers * Array access * Incrementing signed integers

You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from the ones that can't.

[uecker]

The first misunderstanding is that safety is a property of the language or not. Rust marketing convinced many people that this is so, but C can be safe or unsafe. Fil-C shows that even all of C can be memory safe (but at a substantial cost in performance). But even just with GCC and Clang, array access and signed integer can be made safe with a compiler flag, and a violation then traps and this is similar to a Rust panic. The cases which can not be dealt with easily are pointer arithmetic, unions, and free and concurrently related issues. And it is very well possible to isolate and review all of these. This will not find all bugs, but neither does this work perfectly for Rust "unsafe" as this bug (and many others) nicely illustrates.

[wmanley]

I guess that means you're using the colloquial meaning of the word safety/unsafe rather than the rust definition. It's worth being explicit about that (or choosing a different word) in these discussions to prevent confusion.

For Rust safety (meaning no UB) most definitely is a property of the language. If a module does not contain unsafe and the modules it uses that do contain unsafe are implemented soundly then there is no UB.

In C UB is a part of the language.

[uecker]

No, in the comment you reply to, I am using safe/unsafe in the Rust sense. E.g. signed overflow changed to trap avoids the UB.

Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example). It relies on best-effort manual review. (but even without "unsafe" use anywhere, there are various issues in Rust's type system which would still allow UB but I agree that this is not that critical)

In C UB is part of the ISO language specification, but not necessarily part of a specific implementation of ISO C. If you argue that the ISO spec matters so much, I like to point out that Rust does not even have one, so from this perspective it is completely UB.

[aw1621107]

> Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example).

Don't those also depend on implementations being sound? Fil-C has its own unsafe implementation, formal verification tools have their trusted kernels, it's turtles all the way down.

[noosphr]

The safest computer is a rock.

The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.

Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.

[josephg]

> when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe.

Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it.

> The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.

Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.