On Jun 29, 2010, at 8:05 PM, Jordy Rose wrote: > The main issue is that the bounds check shouldn't really emit the bug on > its own. But that leaves it in an awkward place, interface-wise. Does it > return a pair of StInBound and StOutBound, and force the caller to do the > feasibility check? Does it return a bool, and supply the necessary state by > reference? It's too bad we need a state whether the check fails or not.
It's not clear what is the right thing to do. I'm fine with the caller doing the feasibility check, but only the checker itself has the detailed information on why it's a bug. > > I wish we could use blocks; I'd just pass in a "bug-reporting" block that > takes an ExplodedNode. Maybe it should take a function pointer? We use callbacks in many places in the analyzer. While we can't use blocks, we can use classes that have a virtual interface, e.g. StoreManager::iterBindings() uses a callback. One can declare local classes to implement said callbacks. It's certainly more verbose than blocks, but it allows one to pass general objects as callbacks. > Maybe we should leave it as is? *grin* We can come back to it later, but this should gradually get refactored and cleaned up. _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
