Happy 10 year anniversary to this tweet! Has memory safety in C++ been solved yet?

https://x.com/CppCon/status/646386191617626112

@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).
@llogiq @Mara C++23 dev here. Its not solved, but it is rarely an issue in high-level development.
@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.

@llogiq @Mara Could be.

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.

@llogiq @Mara

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.

@Mara The throw_std_committee Reddit acct is an interesting read... they probably know deep down it can't be done*.

* By them, on a timescale that matters.

@cr1901 @Mara they can't do it while making nobody's life inconvenient so they will never do it. Like North America inconveniencing drivers to prioritize cyclists
@Mara yes, of course, just like 2025 is the year of Linux on the desktop ๐Ÿ˜…
@Mara look I checked the runtime value of extern const bool is_memory_safe and it said true so .. either yes, or a buffer overflow overwrote it.

@Mara I mean, Sean Baxter's work on Circle looks pretty good.

...wait the committee did _what_

@cliffle @Mara I'm so out of the loop with C++ lately, what happened with the committee?
@vgarzareyna @cliffle @Mara I believe that they decided that the Safe C++ project required too many changes not just in C++ the language but also in replacing unsafe interfaces, and that they will just use a silver bullet instead.
@specificprotagonist @cliffle @Mara damn, that makes sense... honestly, having to deal with legacy codebases is a hell of an issue sometimes...
@Mara they're very close to proving the PEBKAC theorem
@pr06lefs @Mara thankfully I switched to a standing desk a while ago
"No way to prevent this" say users of only language where this regularly happens

Xe Iaso's personal website.

@Mara An asymptotic process.. that "close to" thingie....

@Mara

That has aged well.

The fine wine idea turned into vinegar.

@Mara I'm so disillusioned; c++ is captured by people who don't understand there's a difference between having possible support for a thing, and having it be easy to use and hard to misuse. At every possible decision point they always choose history over safety. So no matter what they add, only experts who understand decades of history and never make mistakes can use the new stuff that is supposed to prevent mistakes.

@Mara

Yes, it has.

To see how, C++ always reminds me of this somewhat insensitive joke:

A man goes to a tailor to get a new suit. When he tries it on, he complains, "This doesn't fit right at all!"

The tailor says, "No, no, just pull your left shoulder up like this... and bend your right arm this way... now twist your back a little... and tilt your head to the side. See? Perfect fit!"
So the man leaves the shop walking all contorted - left shoulder hiked up, right arm bent awkwardly, back twisted, head tilted.

As he's walking down the street, two people see him.

One says, "Oh, look at that poor man - he's so terribly deformed!"

The other replies, "Yes, but my goodness, doesn't his suit fit him beautifully!"

The man is the programmer. C++ is the suit.

@Mara If someone could share a direct link, I don't feel like searching for a video of that talk right now, but it could just be a catchy slogan that simply emphasized that more and more things are becoming constexpr.
@Mara some of them started using Zig, somehow concluding that it is memory safe ๐Ÿ™ˆ
Safe C++ proposal is not being continued

One year ago, the Safe C++ proposal was made. The goal was to add a safe subset/context into C++ that would give strong guarantees (memory safety, type safety, โ€ฆ

Simone Bellavia's Web Page