Hacker News Reader

Comment by woodruffw | Hacker News Reader

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption.

Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either sort), especially for less experienced C++ engineers. Some kinds of corruption (like double frees) have become even more common as beginner mistakes, in my experience, thanks to the complex mental model required for move construction (compared to Rust, where moves are statically checked).

View on HN

I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?

Nothing great, unfortunately -- C++'s decision to leave moved-from values in a "valid but unspecified" state makes a lot of sense from a memory corruption perspective, but has caused plenty of logic bugs in my codebases as well.

The best thing I've used so far is clang-tidy (specifically the "use-after-moved"[1] check). It catches some stuff though, which is better than nothing.

[1]: https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-...

Good point about clang-tidy. JetBrain's C++ IDE called CLion directly integrates clang-tidy. It is scary how good are some of the suggestions. Absolutely, it makes me a better C++ programmer! It feels like an oldster is tapping me on the shoulder while pair programming: "That one, over there, fix it."

It's well defined safe to use a vector after a move:

    Move constructor. Constructs the container with the contents of other using move semantics. Allocator is obtained by move-construction from the allocator belonging to other. After the move, other is guaranteed to be empty().

https://en.cppreference.com/w/cpp/container/vector/vector

Which can be a useful property at times, but also means tooling won't help you here since it's not an obvious bug.

What he probably means is he imagines the moved-from vector still has elements in it, and indexes into the empty. Another argument for at() outside loops.

Yes, and most algorithms are "surpising" when a container is empty. Most people write, then read, algorithm code imagining a container full of elements. I've been caught by that "bug" so many times, that I now annotate (Java) when containers can be empty. The first few times co-workers see it, they are confused. They they re-read the code, and "oh, I get it. when empty, the code path is very different!" Unlike nullable values, empty collections (usually) don't cause exceptions.

But you can use code that introduces memory corruption. Plenty of crates make use of unsafe blocks.

Unnecessary use of unsafe blocks is stylistically discouraged in Rust, so there's a lot less code that has the potential to harbor a memory safety bug, which makes bugs both less likely to exist and easier to spot when doing a code audit before introducing a dependency on third-party code.

Of course: you can call a C function that's unsound, and that unsoundness can make your surrounding Rust program unsound.

This doesn't change the surrounding point however, which is Rust's philosophy of safeness by construction: if a particular piece of code is safe, then no safe (i.e., invariant-preserving) use of it can be unsafe. That alone makes Rust's security properties strictly better than those of C++, where even the modern safer paradigms can violate underlying invariants.

Reply on news.ycombinator.com