Mara BosHappy 10 year anniversary to this tweet! Has memory safety in C++ been solved yet?
llogiq@Mara I'm sure they've already solved it in those modern C++ code bases that I keep hearing about (but lamentably haven't had a chance to see yet).
Jakub Neruda@jakub_neruda @Mara so what does "rarely an issue" entail? What tools do you run? What practices do you follow to avoid things like e.g. iterator invalidation?
@llogiq @Mara I want to delve deeper into clang-tidy for static analysis, but until recently, my codebase was not compatible with clang tools (MSVC toolchain allows many incompatible things). Tried MSVC static analysis, it was not good enough. Tried ASAN at work, but it didn't work well with some more windows-specific linkage options.
I do not store iterators, only use tree dependency hierarchy (no loops) and use functional approaches (like std::ranges) to avoid most common issues.
Still, I sometimes accidentally capture a local reference to item of array and then resize that array (which relocates and invalidates the reference). But since it is local, it is usually super quick to debug and fix. Other issue is when I need to delete objects from array while resolving queue of events/commands where subsequent events might reference the same element. Has to be solved by deferred deletion. I've only encountered a handful of memory errors in past four years.
@jakub_neruda @Mara That makes me worry about the memory errors you didn't encounter.
The hard bit is that you can't definitively prove there aren't any. And the tools to prove anything are hit and miss.
Any time I tried plugging in a static analysis tool into an existing code (both mine and at work), it produced a lot of false positives and nothing useful.
When we tried ASAN at work, it found 9 legit issues, all of them in unit tests, none in actual production code.
Statistically, I worry much more about logical bugs than memory ones. So far, they "cost" me infinitely more than the memory ones.
@jakub_neruda @Mara I agree that logic bugs are a problem even in Rust – although in my experience they are easy to find. i use assertions liberally, so if the data flow fails to fit my mental model, I will get a panic with useful information.
Conversely, memory bugs may be masked by the allocator (depending on the system) or only ever become visible in uncommon circumstances. Running ASAN is great practice, but even that will only check all the code paths that have been taken during the test run with the given data. Tools can usually only detect the presence of bugs, not their absence.
I see very little difference between memory bug that crashes the program and assertion macro that crashes the program. But my view might be skewed due to working a great deal with Windows ecosystem and MSVC - if Microsoft has perfected anything about their system, its crash dumps. They contain all parallel stacks, all unoptimized variables, shows the actual source code (when symbols are appropriately provided). Therefore, I likely have comparable amount of information as you do, even if the crash happened on the customer environment.
I agree with your point about tools being able to detect presence of bugs, not their absence, I was mainly questioning the economy. If maintaining the tool costs way more than dealing with occasional bug, then I am not going to use the tool, even if it sounds really stupid said out loud like this.