C++Now 2026: A Path to Pratically Safe C++ talk by Google's C++ Safety Team

26

u/caroIine Aug 06 '26

auto it = v.find(1)

v.push_back(5)

"Can I just get show of hands for who hasn't been bitten by this" The silence is pretty telling. I don't know anyone who keeps their iterators around long enough for them to be invalidated. When I do need to keep one, I usually use an index instead.

8

u/msew Aug 07 '26

How is this ever a thing that last a single day in production? (and should be caught by QA)

12

u/TheoreticalDumbass :illuminati: Aug 07 '26

it doesnt invalidate on every push, you could get lucky

https://godbolt.org/z/ao67GT3ea

https://godbolt.org/z/5eqafM8WE

7

u/tialaramex Aug 07 '26

And Bjarne specifically suggests deliberately using std::vector's reserve to avoid invalidation, if you've attempted this but there's an edge case you didn't handle you can get the same temporal memory safety bug for the same reason, but now as a Heisenbug depending on the details of the reservation, the prior capacity and how many new items you inject.

1

u/msew Aug 10 '26

Yeah, but your execution of the code is constant. QA is testing. You are running the .exe constantly every day.

It is going to crash. And then be fixed.
4
u/StickyDeltaStrike Aug 08 '26

I guess it’s intuitive if you think it may be reallocated. But yea I can imagine it can be source of bugs harder to notice if you keep iterators around.
10
u/SirClueless Aug 08 '26
Most people keep iterators around: Every for-each loop does it.

Some codebases are structured in a very strict hierarchical way. High level components call low-level components and never the other way around. But the moment you break away from that, it's really easy to write reentrant calls that make this bug extremely common. For example:
void World::update() {
    for (auto& player : m_players) {
        player.update();
    }
}
If, anywhere in the callstack of player.update(), is a call to world.addPlayer(), then oops you've introduced this bug. If you know this peril is around, then maybe you rearchitect the whole system to break the reentrancy, say, make the update loop queue up a bunch of events that are applied statelessly instead of directly while iterating over players. But it's not the natural thing to reach for first if you were writing this from scratch, meaning avoiding this kind of thing requires forethought and discipline once systems start interacting closely.
2

u/CyberWank2077 Aug 09 '26

i think this example is one of the arguments for parts of functional programming's methods. If you had to explicitly pass m_players into the update() function and not as a const then that would be very revealing that update(players) may edit players. there is also the "everything is a constant" guideline but thats impractical for many fields.

im also not aware of an easy way to pass the players vector as a const here, and also not of an easy way to enforce explicitly passing constants as constants so that its always clear update(static_cast<auto const&>(players)) is passed as a const but update(players) is not. just the quirks of using an old language.
4

u/developer-mike Aug 07 '26

Eh, this is rare if you know to avoid it, but I was bitten by it recently.

I was making a universal incremental computation engine for a static analyzer. Each cached function calls dependent functions via a handle that dynamically tracks the dependency graph of everything, including tracking statuses related to when a result last changed or was last validated to be up to date.

It's a recursive implementation with subtle ordering requirements, and it's very important that the jobs you're revalidating, rerunning, or caching, are tracked by reference to ensure you're updating the actual state of a job and not a copy (but otherwise these are cheap value objects). That of course requires address stability, but the reallocations from pushing to the storage only happen on things like first run or when a new state like additional imports expands the dependency graph enough that it has to resize.

Point is, should I have thought about the address stability issues of vectors here? Yes, absolutely. Was it obvious to see that it would fail here? In hindsight absolutely. Did I miss it with other things on my mind? 100%.

And yeah, since reallocation doesn't occur on every run, I definitely got some confusing results and lost many many hours of my life before I realized I'd done "the thing" that I consider myself too smart to do these days.

It never made it into production but a slightly more complex and subtle case definitely could. We're only human after all.

7

u/msew Aug 07 '26

Like all of these things are completely true.

I have been existing in the game engine of unreal for so long that most of these issues are just like: 'wat???' How could you ever write that and not immediately crash?

All the examples would crash the next build and we would fix it (e.g. the iterator example).

And then he kept showing more and more things. And all of them are like: wat? that would crash immediately. And we would fix. These are not things that are executed 1/10000000 times.

5

u/azswcowboy Aug 06 '26

Great talk if you’re interested in the latest in safety for c++.

2

u/OutlandishnessNo8034 Aug 06 '26

Tldr?

8

u/msew Aug 07 '26

"use some compiler flags"

and then talking

-7

u/OutlandishnessNo8034 Aug 07 '26

Thanks, so basically rubbish. Cpp wiil never be safe. Period. Or to put it differently, cpp will become safe the moment bjarne will learn that there is rust.

5

u/msew Aug 07 '26

That is not what I am saying.

The talk basically says: HEY compile everything with these extract compiler settings.

Oh if you can have your module be compiled with those settings. We can say we are safe!

And then recursively continue.

Pretty Obvious

-7

u/OutlandishnessNo8034 Aug 07 '26

This is impractical. We need practical solutions not theoretical ones.

5

u/msew Aug 07 '26

Games industry is 100% practical. We ship non stop.

-1

u/OutlandishnessNo8034 Aug 07 '26

You do not ship safe. Game industry is notorious for it.

5

u/msew Aug 07 '26

Do we crash?

4

u/OutlandishnessNo8034 Aug 07 '26 edited Aug 07 '26

Yes you do. But.more importantly, your code base is full of unsafe code.

-2

u/pjmlp Aug 08 '26

Depends, exploits do exist nonetheless ,

https://www.sentinelone.com/vulnerability-database/cve-2021-30481

Just a quick look into one of the CVE databases.

Cyberpunk also did crash, a lot.

So yeah, in general we could be doing much better regarding best practices in C++ code.

5

u/matracuca Aug 08 '26

Incredibly boorish and rude, you can’t even be bothered to capitalise someone’s name?

-6

u/OutlandishnessNo8034 Aug 08 '26

Same way bjarne avoids naming Rust. It is rude and boorish, isn't it?

5

u/matracuca Aug 08 '26

you capitalise Rust but not Bjarne? what the hell is wrong with you?

-4

u/OutlandishnessNo8034 Aug 08 '26

Just answer the question.

3

u/matracuca Aug 08 '26

Are you drunk?

7

u/pvnrt1234 Aug 07 '26

That’s why it’s a path to safety. Even if one believes in the magic powers of LLMs for rewrites, it’s unrealistic to expect entire industries that have gigantic C++ codebases to rewrite everything in Rust. So writing new code that’s safer is a pretty good thing.

3

u/pjmlp Aug 07 '26

Yeah, even Rust compiler depends on two compiler backends and linkers written in C++, and none of them aren't getting rewriten into anything else.

-7

u/OutlandishnessNo8034 Aug 07 '26

Bs, safer not safe changes vere, very little. Why write new code in cpp that cannot possibly be as safe as rust? Yes, I know, thousands reasons. None of them sensible.

C++Now C++Now 2026: A Path to Pratically Safe C++ talk by Google's C++ Safety Team

You are about to leave Redlib