Given the following C++ source code: struct S { int a, b, c; S() : a( 0) { b = 1; }; }; then I cannot get gcc to detect the missing initialiser for field c. $ ~/gcc/results/bin/gcc -c -O2 -Wall -Wextra aug2a.cc $ Here is static analyser cppcheck finding the problem: $ ~/cppcheck/trunk/cppcheck --enable=all aug2a.cc [aug2a.cc:8]: (warning) Member variable 'S::c' is not initialized in the constructor. $ cppcheck can find 55 examples of this problem in the gcc source code alone, so it would appear to be of some value to gcc, to say nothing of customers of gcc.
There are several bugs about this already, please search for duplicates.
Bug 19808 is similar but not quite the same. It (and its duplicates) asks for a warning when an uninitialized member is used to initialized another. This one seems to be asking for a warning for members that are left uninitialized, even when they are not used. This would be a noisier warning that -Wuninitialized so it would probably need its own option, but I think it would useful nonetheless. It's likely that there already is a request like this one but I can't find it. Let me confirm this in the meantime.
-Weffc++ catches it: $ $ /usr/local/bin/g++ -c -O2 -Wall -Wextra -pedantic -Weffc++ 81674.cc 81674.cc: In constructor 'S::S()': 81674.cc:5:3: warning: 'S::b' should be initialized in the member initialization list [-Weffc++] S() : a( 0) ^ 81674.cc:5:3: warning: 'S::c' should be initialized in the member initialization list [-Weffc++] $
But -Weffc++ also warns about members that don't need to be initialized, so is useless in detecting uninitialized data.
The patch here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808#c29 once finished should be able to catch this, because it walks the mem-initializer list and marks whatever is initialized. At the end of the list, it could just warn about whatever was not initialized. There will be false positives because it will not look at the body of the constructor but this is something that could be improved later and, in any case, it will never be fixed because it is as hard as -Wuninitialized.
Reconfirmed with GCC 11. See also pr78391. The patch in pr19808 comment 29 was either never committed or even submitted, and the other patch for the same bug submitted last November (https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html) wasn't approved. Let me CC Marek to see if plans to resubmit it for GCC 12.
(In reply to Martin Sebor from comment #6) > Reconfirmed with GCC 11. See also pr78391. The patch in pr19808 comment 29 > was either never committed or even submitted, and the other patch for the > same bug submitted last November > (https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html) wasn't > approved. Let me CC Marek to see if plans to resubmit it for GCC 12. the patch for pr19808 has been committed now