On Nov 24, 2009, at 6:42 PM, Zhongxing Xu wrote: >> A more general problem that we should discuss is how to we want to handle >> model transfer functions (via the Checker interface) that don't just handle >> pre- and post- conditions, but also the entire effects of the called >> function/method. Currently the GRTransferFuncs object has this >> responsibility, but as we've discussed off the mailing list we'd like to >> move in a direction where GRTransferfuncs is no longer needed and we have a >> way of nicely composing transfer function logic for the evaluation of >> function calls. This also needs to interact nicely with our plans for >> (optional) interprocedural analysis via inlining. Once we figure out that >> solution, we can also remove all the OSAtomics logic out of GRExprEngine as >> well. >> > > I remember we didn't say to remove GRTransferfuncs. I proposed to use > it to decide some big evaluation scheme, like intra- vs inter- > procedural analysis. We implement different EvalCall() in transfer > functions.
Yes, I remember now that's what we discussed, so I think I was uttering a thought as it was being formed. :) I've been thinking recently that the overlap in the two interfaces is so similar it seems a little strange to have both of them. We can still do as you propose, but it seems to me that EvalCall() and EvalObjCMessageExpr() could potentially be migrated to Checker. We can possibly chain calls to Checker::EvalCall(), just like we do in CheckerVisit() except instead of always running all the checks we stop when any of the checkers generate any nodes. I'm not certain if the idea would work, but this possibly could allow us to compose analysis logic where domain-specific knowledge about specific checks could be handled in one Checker (e.g., the semantics of the OSAtomic functions) and then at the end of the chain of Checkers we call a Checker that handles the "general case". That would be the same as calling GRTransferFuncs::EvalCall(). This seems to provide the same functionality as we have now, gets rid of the extra interface, and gives us some more flexibility. The redund! ancy of the two interfaces has been really bothering me, as they do basically the same thing. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
