This is the government's strongest stance yet on software security, which puts manufacturers on notice: fix dangerous coding practices or risk being labeled as negligent.
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 it 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, …)
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
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 it 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++
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.
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