<div class="gmail_quote">On Tue, Apr 5, 2011 at 11:11 AM, 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;">
The problem is that the analysis currently treats 'x' to be initialized, regardless of whatever is in the initializer.  This is done to halt the propagation of uninitialized values warnings, and only report the earliest instance.  The real fix probably needs to be done in the analysis (UninitializedValues.cpp), not in the error reporting side in AnalysisBasedWarnings.cpp.</blockquote>
</div><br><div>Interesting! I didn't realize this subtlety, thanks for pointing it out. Sorry for not adding a test case that would exercise it and seeing it, I misread one of the existing tests as covering this... my bad on that front.</div>
<div><br></div><div>I'm looking at this and I wonder what the best way to do this is. Clearly we need to not flag 'x' as initialized in UninitializedValues.cpp.</div><div><br></div><div>Do we want to avoid marking the initializer's reference an uninitialized use inside of UninitializedValues.cpp and remove that logic from AnalysisBasedWarnings?</div>
<div><br></div><div>Or do we want to just prevent the variable from being marked as initialized in this particular case, and handle any and all suppression or other logic inside AnalysisBasedWarnings?</div><div><br></div>
<div>I lean toward the latter as it keeps the model in the analyzer more pure. Even this much special casing in UninitializedValues.cpp seems really unfortunate. How important is continuing to warn on later uses of 'x'? I think its probably worthwhile to have the analyzer propagate through this one layer, but it seems a bit close.</div>