> On Sep 15, 2014, at 1:59 AM, Anders Rönnholm <anders.ronnh...@evidente.se> > wrote: > >> Hi, >> >> I feel that to change this checker and the null dereference check would take >> a large amount of time compared to what is gained, time which could be used >> more efficiently on other checkers. >> The null dereference check is already completed as path sensitive and works >> well. >> >> We are talking about converting only the "check after division/dereference" >> (not regular div by zero or dereference checks) because these checks require >> all paths reasoning (See the "[cfe-dev] [RFC] Creating base class for 'Test >> after X' checkers" thread). The main win is >speed (flow sensitive analyzes >> are algorithmically much simpler than the path sensitive ones), which also >> opens a possibility of converting this into a compiler warning. >> >> I agree that it would not be a very easy task, but this is the right way to >> approach the problem. >> >> I agree with Anna. Doing this because it's convenient is really just >> technical debt and isn't something we'd necessarily be comfortable moving >> out of the "alpha" package, meaning that plenty of users won't even know it >> exists. I can see us very easily never coming back to >do the "right" thing >> here. >> >> Jordan > > We still need to know more of how to do the "right" thing. Can you help us > more on how to do it cfg-based? Do we need to create our own LiveVariables > class for our checkers and then observe it like DeadStoresChecker observes > LiveVariables? >
Consuming the result of data flow analysis in a checker is a good approach for producing static analyzer warnings. I can think of one reason that might need to change; specifically, if the analysis is cheap enough to turn it into a warning. It is hard to say if that will be the case ahead of time. Anna. > //Anders _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
