Thanks, r160330.
On Mon, Jul 16, 2012 at 4:53 PM, Ted Kremenek <kreme...@apple.com> wrote:
> On Jul 16, 2012, at 1:06 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
>
> On Mon, Jul 16, 2012 at 12:55 PM, Ted Kremenek <kreme...@apple.com> wrote:
>
>>
>> On Jul 15, 2012, at 10:14 PM, Richard Smith <rich...@metafoo.co.uk>
>> wrote:
>>
>> The patch replaces the 'track the last DeclRefExpr we saw' technique
>> with a separate pass to classify the DeclRefExprs as use or initialization.
>> Fixing this exposed some "false" positives on some benchmarking code which
>> looks like:
>>
>> void f() {
>> volatile int n;
>> for (int i = 0; i < N; ++i)
>> n += f();
>> }
>>
>> ... so the patch classifies compound-assignments as neither
>> initialization nor use (it leaves the variable uninitialized if it was
>> before, and leaves it initialized if it was before).
>>
>>
>> Hi Richard,
>>
>> One comment on this last point. We tend to like avoiding the
>> uninitialized value taint propagating after the first use to avoid a
>> cascade of warnings. Your last comment here implies that were we to flag a
>> warning at "n += f()" we might also flag another warning later if 'n' is
>> used again. Is that true?
>>
>
> -Wuninitialized only produces one warning per variable. That's handled in
> the Sema layer; the Analysis layer reports all uninitialized uses. My patch
> doesn't change that side of things.
>
>
> Right, makes sense. Overall, this patch looks good to me, and is a nice
> cleanup.
>
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
