4 ms·
This is interesting, but it feels like the beginning of a path to nowhere, since it only addresses bad downcasts and none of the other memory safety problems in
by pizlonator 2y ago
This is interesting, but it feels like the beginning of a path to nowhere, since it only addresses bad downcasts and none of the other memory safety problems in C/C++. It's totally unclear if the technique they propose could compose with other memory safety techniques to get us to a memory-safe C++.
Also their story about finding allocation sites using static analysis is wishful thinking. There's just too much code out there that does super funky stuff at allocation sites.
And they forgot to cite Fil-C (and Fil-C++), which does achieve full memory safety (and has a complete story for what happens in downcasts). They also forgot to cite a lot of their other competition.
- ok123456 2y agoIt's a low-cost way to eliminate a whole class of C++ memory usage errors that typically arise at API boundaries. If g++ or clang offered this as a flag, I'd turn it on.
- pizlonator 2y agoWould you though? You’d pay a cost and you’d still have a dumpster fire of memory safety bugs. Not to mention you’d have to make code changes to be able to use it.
- wakawaka28 2y agoYou make it sound like using C++ guarantees memory safety bugs. It most certainly doesn't. Competent C++ programmers don't create many memory safety bugs at all, and consider them easy to fix in general.
- pizlonator 2y agoI am saying that, yeah. Because it’s true.
- wakawaka28 2y agoLike I said, you're wrong.
- pjmlp 2y agoUnfortunately they are quite hard to come by, as proven by CVE database.
- ok123456 2y agoYes. Any place that required changes or pragmas because of more restrictive semantics should be a warning lamp.
- pizlonator 2y agoSounds like busy work for nothing. Bad casts account for a minority of memory safety issues. It’ll cost nothing for attackers to look elsewhere. So adopting this will more non zero work for zero gain.