On May 9, 2011, at 4:38 PM, Rui Paulo wrote: > Hi, > > On May 9, 2011, at 4:09 PM, Ted Kremenek wrote: > >> Hi Rui, >> >> Two comments/questions: >> >> 1) Please do not use tabs. Please only use spaces (to follow LLVM coding >> conventions). >> >> 2) What is the role of lockHistory? >> >> From what I can tell, lockHistory is trying to record information about >> events along a path, but it is doing so using state in the checker object. >> This isn't the right approach. Because the checker can be used to explore >> multiple paths in any arbitrary order, all checker state needs to be in >> GRState. Think of checkers as memory-less objects that cause state >> transitions in the GRState. Checkers can have state, but they are usually >> used to memoize computation. Any checker state for tracking the evolution >> of a bug along a specific path needs to be encoded in a GRState directly >> (and then ideally removed when it is no longer needed). > > > Oh, right. The role of lockHistory is to track all the locks that we haven't > yet unlocked. The current "state" also does this, but I don't think it keeps > an order. I'll have to investigate further. It would be great if I didn't > need to add anything to GRState. I'll also work on the test cases on my next > opportunity.
You can possibly use an ImmutableList to track lockset ordering (if ordering matters), and use the ImmutableList as the lockset data in GRState.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
