[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.
Thanks,
- 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