3 ms·
The example in the article is something that, for the past decade or so, has been discouraged more and more strongly and is almost entirely unnecessary: Manuall
by einpoklum 4y ago
The example in the article is something that, for the past decade or so, has been discouraged more and more strongly and is almost entirely unnecessary: Manually allocating and freeing memory (plus letting a variable outlive its use and be used for something else).
See:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-resource https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
and specifically, guidelines R.10, R.1 and R.3.
See also this answer:
https://stackoverflow.com/a/48046118/1593077 https://stackoverflow.com/a/48046118/1593077
to the question of why C++ doesn't have a garbage collector.
To be more concrete, the example would be written today as:
{
auto foo = std::make_unique<Foo>();
}
foo->Process();
the last line won't compile - foo is gone already; and if you moved it inside the block scope, then foo would be valid.
Now, the guidelines I mentioned can also be partially statically-checked, and some IDEs have begun to do so, so that the original snippet would give you at least 3 or 4 warnings. Interestingly, this will be true in a larger codebase as well, despite the claim in the article that
> UAFs are often hard to spot in larger codebases where ownership of objects is transferred between various components.
and that's because if you adhere to the coding guidelines _locally_, but throughout your application, including also I.11 about ownership transfer, then you can never free a pointer you don't own (unless you explicitly decide to do so), and you can even avoid dereferencing null pointers. Yes, I meant what I said: You can simply avoid ever dereferencing a null pointer.
All of this is supported by static analysis, so you absolutely don't need to be a virtuous and skilled coder to avoid such conundrums.
---
There's a caveat though: If some of the code is not under your control, but is rather some 3rd-party library or header, then what I said only applies if you properly "sanitize" at the boundaries of your well-checked.
- pebal 4y ago> See also this answer: > https://stackoverflow.com/a/48046118/1593077 https://stackoverflow.com/a/48046118/1593077 > to the question of why C++ doesn't have a garbage collector. The shared_ptr is an optional garbage collection based on reference counting. Slow, leaky, deterministic (that's an advantage and a disadvantage). C++ needs optional garbage collection if needs shared_ptr.
- pjmlp 4y agoC++11 introduced APIs for optional GC and since no one has ever fully provided one, it is going away on C++23. The way C++/CLI, C++/CX and Unreal C++ work isn't based on those APIs (naturally, given their domain), and are even used on the C++23 motivation paper as why those GC APIs should be removed.
- pebal 4y agoThe hazard pointer is basically a proposal to implement GC to solve one implementing problem in C++26.
- wffurr 4y agoITT everyone latching on to the simplistic UAF example, which is obviously not how actual UAFs happen in Chrome or most other production C++ codebases. The article specifically mentions smart pointers and their limitations.
- einpoklum 4y agoMy comment regards more complex scenarios. The article describes what it claims to be limited mitigation efforts; but what I commented about is how they make the problem go away, if you actually use them. If you have some smart pointers but also allocate and deallocate memory manually in all sorts of places in your app, and transfer ownership via raw pointers, then - yeah, you might have UAF problems. In 2011 you could have blamed the lack of language features and library facilities to avoid this; but those days are over. UAF problems are now pitfalls you have to actively and knowingly walk into, they don't just happen. There are other issues with safety which still happen, like out-of-bounds access, which don't have this kind of "effective inoculation"; so it's not as though C++ is now a completely safe language. But UAFs are now mostly a non-issue.
- wffurr 4y agoSo in other words, UAFs are a non-issue except in every actually-existing large production C++ codebase in the world. Thus no point in investigating memory safety techniques?
- einpoklum 4y ago> in every actually-existing large production C++ codebase in the world C++98-style actually-existing large production C++ codebases, you mean. I suppose there's use in mechanisms for improved safety for outdated code, sure.
- saagarjha 4y agoChrome ships with half a dozen pointers that are "smarter" than the code you mentioned. There are still issues because of thread safety and needing to extract dangling pointers at times.