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

David Blaikie dblaikie at gmail.com
Mon Apr 9 16:51:06 PDT 2012

On Mon, Apr 9, 2012 at 4:26 PM, Evan Wallace <evan.exe at gmail.com> wrote:
> On Mon, Apr 9, 2012 at 3:54 PM, Jordan Rose <jediknil at belkadan.com> wrote:
>> I like this idea, though like David said it might not be great for all
>> projects. I think it should be off for POD structs, though, like your first
>> example:
>> > // warning about a
>> > struct A { int a; };
>> I think fewer people mistakenly expect POD structs to be initialized, and
>> of course initializing 'a' would make the struct no-longer POD. The issues
>> I've come across while working with Clang are always POD members in non-POD
>> structures. What do you think?
> That makes a lot of sense, especially for compiling C-like code. I like that
> much better. I've updated my patch with test cases and a check for POD
> types. I'm still not sure where to put this diagnostic. It's tentatively in
> a new warning called -Wuninitialized-member in the -Wextra group. Is that
> the best place for it, or would it fit better somewhere else?

Where's GCC going to put it?

I'd also consider the phrasing of the diagnostic a little, perhaps

"member %0 is not initialized in the constructor initializer list"

Though I'm not too fussed on this front.

Have you tried/got tests with non-trivial types that don't need to be
explicitly listed in the ctor to be safe?

struct foo { foo(); };
struct bar { foo f; bar() { } }; // don't tell me that 'f' needs to be
in the init list

You don't need to test the DiagnosticLevel - just emit the diagnostic
& the underlying machinery will take care of printing it out, or not.
The only time we check the DiagnosticLevel is if we're going to do
substantial/non-trivial work to diagnose the problem - if the warning
is off, we can save ourselves from doing all that work.

- David

> - Evan
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list