[cfe-commits] r159620 - in /cfe/trunk: lib/Analysis/UninitializedValues.cpp test/Sema/uninit-variables.c

[Richard Smith]

On Tue, Jul 3, 2012 at 1:27 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Tue, Jul 3, 2012 at 12:37 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > On Tue, Jul 3, 2012 at 1:14 AM, Joerg Sonnenberger <
> joerg at britannica.bec.de>
> > wrote:
> >>
> >> On Mon, Jul 02, 2012 at 11:23:05PM -0000, Richard Smith wrote:
> >> > Log:
> >> > -Wuninitialized: assume that an __attribute__((returns_twice))
> function
> >> > might
> >> > initialize any variable. This is extremely conservative, but is
> >> > sufficient for
> >> > now.
> >>
> >> Can this be reduced to following both code paths if the function call is
> >> part of a conditional?
> >
> >
> > I'm not sure what you're suggesting; we do follow both code paths after a
> > conditional. If you mean that we should track whether the function
> returned
> > a nonzero value, and not apply this logic in that case, then I think
> that's
> > out of scope for this check, and belongs in the static analyzer (if
> > anywhere).
> >
> >>
> >> When I analysed the newly triggered warnings for
> >> -Wuninitialized in NetBSD, setjmp usage was something like 50%
> >> questionable w.r.t. conditional initialisation, so getting this more
> >> strict or optional is definitely a good idea.
> >
> >
> > If we want to make this smarter, I think the way to approach it is to
> find
> > variable initializations which are reachable from the returns_twice call
> > (optionally only looking at ones where there is a function call
> afterwards),
> > and to assume that all relevant variables are initialized by the setjmp
> > call. But we would need to find an inexpensive way of computing this
> > information. Perhaps a reasonable tradeoff would be to compute a set of
> > variables which are initialized anywhere within the function, and to
> assume
> > that setjmp initializes them all.
> >
> > It might also be valuable to separate the setjmp case (which needs this
> > special handling) from the fork case (which does not), but we don't
> > currently have attributes to track that.
>
> Err, IIRC we don't mark fork() as returns_twice.


Sorry, I meant vfork :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120703/6e8293fa/attachment.html>