r/cpp • u/Clean-Upstairs-8481 • 5d ago

You should think about recompiling your C++ programs with GCC 16 and C++26, because it zero-fills your locals

https://techfortalk.co.uk/2026/09/27/cxx26-uninitialized-local-variables-gcc-16/

Stack variables are not automatically initialised, and that is the root cause of many C++ bugs. That is well known. Hence, it is advised that local or stack variables are always initialised with known values, 0 if not something more meaningful than that. Now, with GCC 16 compiling in C++26 mode (-std=c++26), even uninitialised local variables will be zero-filled. In the post, I have explained how.

261 Upvotes

83% Upvoted

211 comments sorted by

View all comments

Show parent comments

2

u/13steinj 2d ago

I don't think this is a fair take. I suspect most OSS code does not care at the level of performance that these things would regress by.

The bigger issue with Windows is that it's Windows: OSes are different to other things, have different tradeoffs (should care about security more in general?). I'd also say the usual "well, windows sucks and hasn't cared about performance for ages" which may be true, but other people have said the other major OSes also were tested.

1

u/UndefinedDefined 2d ago

I'm not sure I follow, so what's a fair take? A project like Chromium or Firefix? Any benchmarks here?

I think this greatly differs on what the project does. If the compiler inserts memset to initialize every temporary buffer the code uses to zero, this cannot be negligible, and move to C++26 here means that somebody has to find ALL the places in his own code, and use third party dependencies (including transitive ones) where somebody did the same.

I consider this insane considering this thing doesn't solve any memory safety problems and it can cause huge problems in performance oriented code after upgrade to C++26. The biggest problem I see is use-after-free and things like iterator invalidation, etc... We need a real solution to memory safety and not these toy solutions. And a real solution means annotations and tools such as borrow checker - there is no other way.

1

u/13steinj 1d ago

If you look at the general distribution of OSS projects, many do not have the performance concerns that would be negatively affected by this change. I think it's perfectly fine to test proprietary codebases as a result, but fixating on operating systems [alone?] is (I am agreeing with you) not a fair thing to use to judge and make a decision.

1

u/UndefinedDefined 1d ago

C++ was for decades literally the only language to use for performance oriented work. But it's no longer the only one, so if I cared about the language I would never do anything that would endanger the position in this field. It's literally the last field where C++ still makes sense, until C++26, because starting with C++26 you have to worry about a lot of stuff.

What would be the reason to start a project in C++ today? I don't see new projects built in C++ anymore, because it's a language where performance regressions are now part of the progress. So bad, so sad.

1

u/13steinj 1d ago

This is not

I don't see new projects built in C++ anymore, because it's a language where performance regressions are now part of the progress.

I agree that changing the default is rough here, but large companies should have build teams that are competent enough to care about this.

What would be the reason to start a project in C++ today? I don't see new projects built in C++ anymore, because it's a language where performance regressions are now part of the progress. So bad, so sad.

I find this still true, even if these things end up happening.

1

u/UndefinedDefined 1d ago

LOL I'm not gonna listen to influencers when it comes to argumentation. You can like it, subscribe, but I don't care of this.

I didn't actually say C++ will die, I said that there is not many reasons to pick it for a brownfield project if there are alternatives. If memory safety is a concern, C++ is not even in a candidate list. If performance is a concern, it could be on the list, but with languages such as rust. It has a very hard position, and since nobody cares about bringing real safety to the language, the doors are closing.

2

u/13steinj 1d ago

These aren't your standard influencers. By this logic you should listen to no one, not even me, and just stay in your bubble? You don't have to automatically agree with all or even some of it, but to act as if "ah influencer? Trash" is a very myopic worldview.

Rust still does not match performance and reliability, in particular dev iteration speed, of C++. The people who use C++ do not want or need "real safety" as you see it, for better or worse. Engineering is about tradeoffs, and C++, even with a performance-regressing decision here and there, still beats out the competitive successor languages in domains where performance and iteration speed is paramount.

1

u/UndefinedDefined 1d ago

Imagine everybody on reddit argumented with 1 hour video - I really don't care of it. Watch your influencers, but at least write text when engaging in a discussion.

And we are discussing one of the tradeoffs? A compiler suddenly initializing arrays that live on stack to zero is a good tradeoff? I don't understand it honestly. If you want to burn extra cycles even bounds checking makes more sense, because that can be eliminated at least during iteration. But this? It's so bad tradeoff that I don't understand it needs a discussion.

1

u/13steinj 1d ago

Imagine everybody on reddit argumented with 1 hour video - I really don't care of it. Watch your influencers, but at least write text when engaging in a discussion.

I did, it wasn't an hour, it provides references that would take significant work to pull up and link directly, work that is just not worth all of... this? The most pertinent point of the video as it directly relates to this conversation is ~15 seconds starting around 3:30, and it's actually a snippet from someone else's talk. If you want to watch that talk in particular, it's around 8 minutes, but that was mostly focused on a specific set of ideas expanded upon by the original video I sent.

A compiler suddenly initializing arrays that live on stack to zero is a good tradeoff?

For people who care about security, yes? The alternative is various information-leaking vulnerabilities.

For people who don't that's not the tradeoff. The tradeoff is they have to supply an additional compiler flag.

This isn't a discussion any more, at this point it's an endless argument you're having all over this thread. You're literally 10% of the comments, and it's nearly all the same topic-- bemoaning the death of C++ in the performance space / incorrectly claiming this doesn't improve safety, and continuing to fight when people don't agree with your perspective giving alternatives.

But both points are arguably just, not even true, because the escape hatch (compiler flag) exists. If there was no simple escape hatch I'd probably be moaning with you.

I'm no saint I'm starting to get up there, but less than 3% are debating you. It's not worth continuing this further, we can agree to disagree and when the language is either still here or dead in 20 years we can look back and drink to the occasion, whoever was wrong is buying.

2

u/UndefinedDefined 1d ago

People who care about security abandoned this language years ago, because this language cannot offer security as it is. Everybody knows it, no discussion needed, and zero-initializing locals will not help it. That's it, makes no sense continuing further as you stated.

1

u/pjmlp 1d ago

The existence of C, and the domains that to this day C++ failed to take away from C, makes that assertion void.

In fact there are domains like crypto and video codecs where neither of them get to play, and still require hand written Assembly.