https://bugs.kde.org/show_bug.cgi?id=440893
--- Comment #2 from Bob Stafford <bobst...@eecradar.com> --- Hi Tom, Thanks for the reply. Apologies if you got this twice, I think my first attempt to send failed because I sent it from a different variant of my company email address. It seems you're right I think this section in the page you mentioned is the key part "Default initialization of non-class variables with automatic and dynamic storage duration produces objects with indeterminate values (static and thread-local objects get zero initialized)" It's strange that in my case the data block is always filled with 0's (abort() is never called), I'm using gcc 8.5.0 and c++17. I guess there's nothing to say the compiler (or library) cannot zero the data if it wants to but I'll stop relying on that behaviour. Just for my information is there a reason why valgrind only complained about the first element of the array being uninitialized, and not the rest of the array? Cheers Bob S. On 8/12/21 6:02 AM, Tom Hughes wrote: > https://bugs.kde.org/show_bug.cgi?id=440893 > > Tom Hughes <t...@compton.nu> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REPORTED |RESOLVED > CC| |t...@compton.nu > Resolution|--- |NOT A BUG > > --- Comment #1 from Tom Hughes <t...@compton.nu> --- > I think you are confused... > > When there is no initializer the array new operator in C++ performs default > initialization of each member of the array > (https://en.cppreference.com/w/cpp/language/new#Construction). > > Default initialization for POD types like char does nothing > (https://en.cppreference.com/w/cpp/language/default_initialization). > > Therefore that memory is uninitialized and valgrind is correct. > -- You are receiving this mail because: You are watching all bug changes.
