<div class="gmail_quote">On Thu, Feb 3, 2011 at 10:34 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.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="im">On Feb 3, 2011, at 9:34 PM, Nico Weber wrote:<br>
<br>
</div><div class="im">> My personal impression is that it can be difficult to understand when<br>
> this new mechanism warns, and most of the time when it warns, it's<br>
> warns about false positives.<br>
<br>
</div>I'm not certain if the second statement is truly fair.  This is code that has already been vetted for uses of uninitialized values.  Your point is taken, however, that the remaining false positives are noise that GCC doesn't warn about.  The question I'd rather we focus on asking is what should we do about those cases?</blockquote>
<div><br></div><div>While my suggestion above about annotations to indicate acknowledged lack of initialization were intended primarily for performance sensitive code paths, the approach could be used in code paths where humans trivially conclude that initialization isn't needed, and would prefer explicitly saying that rather than doing a redundant explicit initialization.</div>
<div><br></div><div>Improving the smarts of the diagnostic to simply detect the initialization is appealing in the sense that it makes the warnings go away without code changes, but less appealing as you've indicated because it actually makes the warnings less predictable and more expensive to provide.</div>
</div><br>