[cfe-dev] warn when ctor-initializer leaves uninitialized data?

[Evan Wallace]

Thank you all for your responses and for the awesome feedback. I think
there are a couple of different ideas in this thread. While it would be
fantastic to try and find uninitialized values in arbitrary code, that
would definitely be a much larger change and I don't think I'm up for that
yet. It looks like -Wuninitialized currently follows the flow of
uninitialized variables within a function and could probably be modified to
also follow members not in the initializer list through the constructor.
However, following flow into other functions can be very complicated and,
as Matthieu brought up, it isn't possible in the general case because the
source for some methods might not even be available. Such a diagnostic
would end up being an approximation and would sometimes either have to
reject valid code or silently ignore invalid code.

I guess the warning I was envisioning was more of a stylistic warning. The
equivalent warning from gcc is -Weffc++ which includes warnings about
violations of several style guidelines from Scott Meyers' book "Effective
C++, Second Edition" including this warning (always put all members in the
initializer list). It includes a few other warnings and is helpful in
preventing mistakes, especially for beginners, but generates a lot of noise
when run on large existing projects and unfortunately can't be split into
separate, fine-grained warnings. The warning in this patch is much more
targeted but makes the choice to reject some valid code instead of silently
ignoring invalid code. It was more targeted for beginner to intermediate
users of C++ and not for large, highly optimized projects. Maybe this wants
to be two warnings, one for initializer lists as it is currently and one
that attempts to trace uninitialized members to the end of each constructor
but doesn't warn when it isn't sure?

- Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120410/f368e631/attachment.html>