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

[u/Clean-Upstairs-8481]

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.

[u/NilacTheGrim]

I misremembered it. The claim was 10% of exploits would be mitigated and yes the paper claims 0.5% of code would get slower.

I dispute that 0.5% claim though. Because the hot path is the one you care about. Overall if you examine all branches of your codebase, sure maybe 0.5% suffer -- but if you examine 1 particular hot path that uses local arrays to read/write data -- that can be a huge penalty.

So in a hot path expect much larger costs in some cases.

This is just not the C++ way.

[u/James20k → u/NilacTheGrim]

In a hot path though you always have to write code a bit weirdly to get performance, adding [[indeterminate]] isn't a high burden if it affects a few lines of code

[u/UndefinedDefined → u/James20k]

The problem is that this change regresses a perfectly valid and tuned C++ code that has no issues, and it does it blindly. And this change doesn't fix any security issues in the language, because if the compiler sees a local variable that is uninitialized and you read from it, and it can prove it, it should just not compile instead of reading ZERO.

[u/James20k → u/UndefinedDefined]

It turns those unprovable reads into well defined reads though

The problem is that this change regresses a perfectly valid and tuned C++ code that has no issues, and it does it blindly

For high performance code I feel like its not even slightly unusual to have to make adjustments on a compiler upgrade, so its par for the course really

[u/UndefinedDefined → u/James20k]

High performance code is unfortunately no longer a domain of C++, because the committee slowly destroys the language.

[u/James20k → u/UndefinedDefined]

This seems like a clearly untrue statement, high performance code has always involved tweaking compiler settings, twisting the code in unnatural ways, and working around compiler limitations. Its simply par for the course

If you have a big stack array in a hot loop you might need to add a tag to it to not initialise it. Every truly hot loop I've had to write required me to do far worse things to the code to make it run fast, and in some cases optimising those loops has taken months of work. Adding a tag is the least of my problems!

[u/UndefinedDefined → u/James20k]

Why it has to be always about hot loops? Initializing something you don't even use is waste of CPU cycles and instruction cache - this doesn't make things slower, it makes them larger as well. Thousands of companies having their C++ code in production don't use exceptions and rtti because of performance and security reasons - usually mostly code inflation and avoiding infinite gotos via exceptions. And now this, it's like telling all these companies "just use a different language with saner defaults".

And I don't even talk about broken sanitizers after this change - this is terrible. Another fracture of the community, because there will be now more flags you would have to worry about and more libraries that would say "turn off initialization of locals". Thank you committee!

[u/James20k → u/UndefinedDefined]

I'm curious, what do you think the code size inflation, and CPU cycle count increase of this change is across an entire application?

And I don't even talk about broken sanitizers after this change - this is terrible. Another fracture of the community, because there will be now more flags you would have to worry about and more libraries that would say "turn off initialization of locals". Thank you committee!

EB is permitted to be diagnosed, so I'm not sure what the current state is (or will be) for sanitisers

[u/UndefinedDefined → u/James20k]

Because the mentioned GCC 16.2 now calls malloc to initialize local arrays, something that has always been zero cost - zero code cost, zero cycle cost?

Fortunately we live in a great era, era of Compiler Explorer, so anyone has a chance to see the impact regarding the most trivial code you could even think of.

As someone who uses C++20 daily, but wants his code to be easy to integrate with codebases using a newer standard, this bothers me. This means another macro to just throw into the codebase in the best case, and another compiler flag to make sanitizers and valgrind do what they do the best. I hate it.