It can still crash

Posted Feb 11, 2025 20:31 UTC (Tue) by NYKevin (subscriber, #129325)
In reply to: It can still crash by jengelh
Parent article: Maintainer opinions on Rust-for-Linux

C++ references are every bit as unsafe as C pointers, at least in the Rust sense of safety. The differences, for anyone who doesn't C++, are roughly as follows:

* A C++ reference must be initialized to point at something, and cannot be NULL (or nullptr).
* A C++ reference points at the same thing for its entire lifetime - it cannot be changed to point at something else (like a const pointer, unlike a pointer-to-const).
* For that matter, there is no syntax to distinguish the reference from the pointee - it auto-dereferences where appropriate.
* For some reason, much of the documentation insists on avoiding the word "pointing" in relation to references, instead claiming that a reference is an "additional name" or "alias" for an object. But they are pointers, or at least there is no practical implementation other than as a pointer (on most reasonable architectures, in the general case, excluding cases where the optimizer manages to elide a whole object, etc.).

There is nothing which prevents you from destroying the pointee out from under the reference, which causes UB if you use the reference afterwards, so it is unsafe. It does prevent a few potentially dangerous patterns such as null pointers and pointers that get changed at runtime, but that is not the same thing as memory safety.

It can still crash

Posted Feb 13, 2025 2:14 UTC (Thu) by milesrout (subscriber, #126894) [Link] (1 responses)

"Every bit as unsafe" is exaggerated. They are memory-safer, but not entirely safe. That being said, I personally think they are much more dangerous. Taking a reference is hidden. Taking an address is not. So you can't tell if f(x) takes x by X or by X&, if it potentially modifies x or not. Rust references are more like C references in that you (usually) need to explicitly write &mut x to get a reference that you can write to the object through (but I think this is not true when you write x.f()).

It can still crash

Posted Feb 14, 2025 12:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Yes, if you use method call syntax (remember this is optional, although it will be more idiomatic in most cases to use method call syntax, Rust can express any method call as an ordinary function call despite not having full blown Universal Method Call Syntax) the transformation makes the appropriate reference types automatically (and so if it couldn't under Rust's borrowing rules that won't compile)

This will also happen if you use an operator, take AddAssign the trait implementing the += operator

description += " and then I woke up.";

... Is eventually just AddAssign::add_assign(&mut description, " and then I woke up.");

So if we lent out any reference to description that's still outstanding, we can't do this, likewise if we only have an immutable reference we can't use that to do this either. But the visible syntax shows no sign that this is the case.

In practice because humans are fallible, the most important thing is that this is checked by the compiler. It's valuable to know that my_function takes a mutable reference, when you're writing the software, when you're reading software other people wrote, and most definitely when re-reading your own software - but it's *most* valuable that the compiler checks because I might miss that, all three times.