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

[Eli Friedman]

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.

-Eli