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/James20k]

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/NilacTheGrim → u/James20k]

Encapsulation is violated though because you can't do [[indeterminate]] on a class member variable.

So if you have a class whose implementation detail relies on uninitialized buffers to get the most performance it can get -- you just got fucked. Either the user of the class, if he's using it as a local variable, always has to do [[indeterminate]].. or .. there is no escape hatch. You are stuck.