3 ms·
ITT 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 art
by wffurr 4y ago
ITT 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.