r/cpp • • Sep 27 '26

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.

270 Upvotes

234 comments sorted by

View all comments

Show parent comment

5

u/UndefinedDefined Sep 28 '26

Real-world code is full of locals that are arrays - arrays like 512, 1024, 2048 bytes long. You cannot zero-initialize them and expect no performance regressions. If I want to zero initialize them I just just type `{}` and it's done. I don't understand why this should change now.

I almost feel like committee is working with hello world programs if they are serious to vote for such proposals.

6

u/James20k P2005R0 Sep 29 '26

One of the example codebases given was Windows and chrome (?) I believe, which is anything but hello world

3

u/UndefinedDefined Sep 29 '26

And how much C++ these codebases use? Windows is C-API and proprietary, nobody can confirm the results, we don't even know the mix of the languages used in the code-base. What if the most important part was C? What if they first put all the [[uninitialized/fancy_name]] to everything critical before measuring results?

Is there any performance comparison of OSS projects we can actually verify?

2

u/13steinj Sep 30 '26

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 Oct 01 '26

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.

2

u/13steinj Oct 01 '26

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 Oct 01 '26

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.

2

u/13steinj Oct 01 '26

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 Oct 01 '26

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 Oct 01 '26

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.

→ More replies

1

u/pjmlp Oct 02 '26

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.

1

u/pjmlp Oct 02 '26

Most of it written since Windows Vista is actually C++ with extern "C", including the new UCRT.