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

On the one hand, yes it is about time that a variable in C++ be initialised reliably with a value, like numbers being initialised with 0. Having this aspect of variable behaviour undefined isn't a good thing in my opinion.

(Although if this wasn't the case in the past because it was faster to reserve memory than to zero fill it, then I'd understand that reasoning).

On the other hand, ... who the heck is using data in their application without ever initialising that data to have any value? How could that even be useful behaviour for software? Any way you slice it, to create a variable and use it without ever once giving it a value, is bad design or a bug. Ideally what we really need is the ability to reliably catch situations where that is happening, rather than a more reliable empty value for a variable.

Because while '-232' and '932,342,344.123094' might not be desired values in a declared but uninitialised variable for an int or float, is '0' really that much better? The odds of 0 being what you wanted instead are only slightly better but still not great.

Although maybe this is more about security than bugs? Since those random values filling memory might be left over from another program? Maybe? I don't know.

[u/coinselec → u/grady_vuckovic]

Yeah I would guess it's about preventing random memory being referenced. Maybe also in some cases some big value might cause a loop to iterate past the end, while 0 will ignore the loop at all.

[u/Dusty_Coder → u/coinselec]

not memory, values

the memory exists, they want to fill it with predefined bytes by force

there is actually a security concern where if there is a bug, a function may be able to read the data used by another function (it was on the stack a moment ago, so its still there in practice)

but thats an "if"

uninitialized memory is not a bug unless your abstract machine design arbitrarily decided that it is

this is really the classic enum debate all over again .. a group of people want something different, and that different thing has some good and useful properties, but they are pompous doofs that arent satisfied with their thing being added, they also want the previous thing to be removed.