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

[Nico Weber]

Hi Evan,

this sounds like a really cool warning. I tried building chromium with
it, here are a few examples where it warns but probably shouldn't:

// Warns about path_ not being initialized (a char[PATH_MAX])
FileID::FileID(const char *path) {
  strlcpy(path_, path, sizeof(path_));
}

  // Warns about members not getting set, but Clear() does that
  KeyValueEntry() {
    Clear();
  }

  // Same thing again
  Var(DontManage, PP_Var var) {
    var_ = var;
    needs_release_ = false;
  }

This warning gave me 9 false positives and 0 bugs in the first 70
files I tried. Initializing variables not in the initializer list but
in the constructor body is a fairly common pattern. Can you think of
ways to make these cases work?

Nico

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?
>
> - Evan
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>