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

[Matthieu Monrocq]

Le 11 avril 2012 04:00, Jordy Rose <jediknil at belkadan.com> a écrit :

> I do think this should still go in, even if it's off by default. Any easy
> checks could be included, any difficult checks should not.
>
> OTOH, we've run into things like this before, and the general rule has
> been that Clang is not in the habit of introducing new style warnings. The
> style warnings we have are generally ones that have historical precedent
> (-Wparentheses). So my personal positive preference may not match up with
> Clang's big-picture goals.
>
> The one thing that would make it nicer is a way to silence the warning
> without initialization, but I can't think of a good way offhand.
>
> My two cents,
> Jordy
>
>
> On Apr 10, 2012, at 16:22, Evan Wallace wrote:
>
> > 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
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
FYI:

Just this afternoon I activated a build with -Wall -Wextra -Werror on gcc
and I had to add a -Wno-missing-initializer because gcc erroneously warns
on:

struct tm timepoint = {};
timepoint.tm_year = 111;

saying that all members other than `tm_year` are not initialized. It is
*really* annoying to put up with such false positives.

So I would be very interested in warning that is never wrong, and maybe Ted
would approve of a specific -Wbeginner group to put warnings that are
potentially wrong but really help beginners ?

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120411/fd5159af/attachment.html>