[cfe-commits] r53964 - /cfe/trunk/lib/Analysis/CheckDeadStores.cpp
Ted Kremenek
kremenek at apple.com
Thu Jul 24 09:43:49 PDT 2008
On Jul 23, 2008, at 11:38 PM, Chris Lattner wrote:
>
> On Jul 23, 2008, at 9:10 PM, Ted Kremenek wrote:
>
>>
>> On Jul 23, 2008, at 5:24 PM, Chris Lattner wrote:
>>
>>>
>>> On Jul 23, 2008, at 3:19 PM, Ted Kremenek wrote:
>>>
>>>> Author: kremenek
>>>> Date: Wed Jul 23 17:19:56 2008
>>>> New Revision: 53964
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=53964&view=rev
>>>> Log:
>>>> Don't flag dead stores when the result of a preincrement/
>>>> predecrement is used in an enclosing expression.
>>>
>>> So you don't warn about "print(++x)" if x is dead after that? Why
>>> not warn "consider changing ++x to 'x+1'"?
>>
>> My reasoning was to reduce noise. Stylistically many people like
>> to do ++x to compute the value used in the enclosing expression,
>> and I'm a little doubtful that warning about these kinds of dead
>> stores will ever find real errors. Thoughts?
>
> If the incremented version of x is dead, I'd suggest reporting it,
> but as a different class of issue than normal dead variable. That
> way people could filter out all the reports (with the check box) if
> their coding style depends on this sort of thing. What do you think?
Yesterday I added support in the dead store checker to distinguish
between dead stores arising from increments and those resulting from
normal stores. Here is an example of dead increments:
++x;
--y;
z += ...
w = w + ...
I also added a check to not emit a warning if the "++x" (not x++)
appeared as a subexpression. I'm thinking now that we should just
warn about these as well if we are already warning about other dead
increments.
> Increasingly, I think that this is a great way to deal with classes
> of false positives that arise do to "weird" coding conventions.
At some point we might also want to have "bug groups" so that people
can group together all dead stores, etc. Right now we have three
kinds of dead store bugs (dead initialization, dead stores, dead
increments), and some people may wish to just filter all of them out
all at once with a single check box. As we get more and more bugs,
having a way to sort and triage large classes of bug reports will be
useful.
More information about the cfe-commits
mailing list