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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
