Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.
Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.
It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)
That’s why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.
To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn’t grow (and thus ref would still be valid, not triggering UB), leading to a production-only bug.
Asan is a wonderfull tool, but you can’t deny it’s much harder to use and much less reliable than just running your compiler.
I think you have a hard time understanding the différence between “not possible” and “much harder”.
In Rust, the code does not compile.
In C++ the code compile, but
if you have a test case
this test case triggers the bug (it is not guarateed to properly reproduce you production environment since it depends on the parameters of the allocator of your vector)
you use ubsan
… then the bug will be caught.
Yes it is possible, noone says the opposite. But you can’t deny it’s harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies.
The
I get what you’re saying, but I think the issue with optional memory safety features is that it’s hard to be sure you’re using it in all the places and hard to maintain that when someone can add a new allocation in the future, etc. It’s certainly doable, and maybe some static analysis tools out there can prove it’s all okay.
Whereas with Rust, it’s built from the ground up to prove exactly that, plus other things like no memory being shared between threads by accident etc. Rust makes it difficult and obvious to do the wrong thing, rather than that being the default.
Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026.
My interpretation is that smart pointers are allowed, as long it’s systematically enforced. Switching to a memory safe language is just one example.
Seems excessive to convert everything to rust when you can use std::shared_ptr and std::weak_ptr to eliminate the memory safety issue?
Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.
To be fair, it’s entirely possible to make the same and very similar mistakes in Rust, too.
I’m fairly sure use after free isn’t possible unless you explicitly use unsafe code right?
It’s compiler enforced is the point.
Yes
Definitively not.
I think you could argue the same point with C++
void foo() { std::vector v = {0, 1, 2, 4}; const auto& ref = v[1]; add_missing_values(v); std::cout << ref << "\n"; } void add_missing_values(std::vector<int>& v) { // ... v.push_back(3); }Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if
v.push_back(3)requiresvto grow, thenrefbecomes an invalid reference andstd::cout << refbecomes UB (use after free). In Rust this would not compiles.It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)
This would be caught by ASan and other tools though, which should be part of any review.
That’s why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.
To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn’t grow (and thus
refwould still be valid, not triggering UB), leading to a production-only bug.Asan is a wonderfull tool, but you can’t deny it’s much harder to use and much less reliable than just running your compiler.
I think you have a hard time understanding the différence between “not possible” and “much harder”.
In Rust, the code does not compile.
In C++ the code compile, but
… then the bug will be caught.
Yes it is possible, noone says the opposite. But you can’t deny it’s harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies. The
I wonder how many issues rewriting everything in another language will create?
Just as many issues as not reading the article.
I get what you’re saying, but I think the issue with optional memory safety features is that it’s hard to be sure you’re using it in all the places and hard to maintain that when someone can add a new allocation in the future, etc. It’s certainly doable, and maybe some static analysis tools out there can prove it’s all okay.
Whereas with Rust, it’s built from the ground up to prove exactly that, plus other things like no memory being shared between threads by accident etc. Rust makes it difficult and obvious to do the wrong thing, rather than that being the default.
From the original document:
My interpretation is that smart pointers are allowed, as long it’s systematically enforced. Switching to a memory safe language is just one example.
I have never seen a single C++ codebase do that. It helps but it’s not a practical full solution.