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

[David Blaikie]

On Mon, Apr 9, 2012 at 10:47 AM, Evan Wallace <evan.exe at gmail.com> wrote:
> Hello,
>
> What would the interest be for a new warning that warns when POD member
> variables are left out of the constructor initializer list and end up
> uninitialized? That's bitten me many times and is especially hard on
> beginners. Please correct me if I'm wrong but clang doesn't currently warn
> about this. It looks like this warning is currently being implemented for
> gcc (bug 2972). I don't have any experience with clang so I'm not sure if
> this is the right place at all, but I took a stab at it last night on a whim
> and it looks like adding the warning at the end of
> BuildImplicitMemberInitializer() in SemaDeclCXX.cpp does the trick. If there
> is interest, would this warning want to be added to the -Wuninitialized
> group or would it want to be separate because it affects a lot of existing
> code? What I have right now looks like this:
>
> basic.cpp:1:22: warning: member 'y' is missing from constructor initializer
> list [-Wuninitialized-member]
> struct S { int x, y; S() : x() {} };
>                      ^

Hi Evan,

Thanks for looking into this. Did you mean to include a patch file of
your current changes?

We'd have to see how accurate this diagnostic was (in finding bugs,
not noise) - my hunch would be that it's probably not accurate enough
to turn on by default, at least. Though that doesn't mean it can't
live under -Wuninitialized (I haven't checked what else is there, how
accurate they are, etc).

A few questions (I think I mentioned these on IRC, perhaps - or just
crossed my mind):

1) how well does this handle unions? struct S { union { int x, y; };
S() : x() {} }; - as an addition to this. I was wondering if we could
roll this checking up into the same machinery we need/could use/have
some of for errors relating to competing initialization (eg: we
currently correctly produce an error when you try to initialize both x
and y in my example)
2) Is there any way to silence the warning without introducing
initializations that may not be required/desired? (one interesting
case I came across in Clang recently is, effectively, a discriminated
union - some members are used/unused based on which enum value is
currently held - there's no need to initialize the other members as
they are dead)

Thanks,
- David