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