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

[Joerg Sonnenberger]

On Thu, Jul 05, 2012 at 03:06:25PM -0700, Richard Smith wrote:
> On Thu, Jul 5, 2012 at 7:14 AM, Joerg Sonnenberger
> <joerg at britannica.bec.de>wrote:
> 
> > On Tue, Jul 03, 2012 at 12:37:44PM -0700, Richard Smith 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).
> >
> > Consider the attached test case. I think we definitely want to warn
> > here.
> 
> 
> With the approach I suggested, we would do so (although for more complex
> cases, we would not). Are you suggesting that we should somehow track
> whether there exists any variable which is used uninitialized irrespective
> of the return value of setjmp? That sounds like a correct criterion, so if
> you have a suggestion for a way to implement it efficiently, that would be
> interesting.

First of all, I'm not sure how desirable tracking the special
returns-twice logic really is. As I said, for NetBSD the number of hits
for the warning was quite low and the majority of them needed some real
thought to prove the warning false (or correct for that matter).
It might be a good idea to start by getting a bit more feedback on the
original behavior.

Second, modelling setjmp explicitly would be an option to cut down on
the number of false positives as well, but that's more involved.

Third, the discussed behavior of tracking all branches involving the
return value and warning if the variable is not initialized in all of
them, but used in at least one would be an option. Sadly, I'm not sure
it can be implemented efficiently :(

Joerg