On Fri, Nov 7, 2008 at 3:39 PM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
> > On Nov 6, 2008, at 10:01 PM, Zhongxing Xu wrote: > > Also I think we should have a clear client for the extent before/when we >> implement the extent mechanism. One direct client is the array element >> access checker. >> > > This can be (potentially) be done in GRExprEngine, just like we handle Null > dereferences. > > It should be in the EvalLocation() method to check if the array access is >> out of bound. >> > > That or EvalLoad(). An out-of-bounds error occurs on a load or store. > > But not all store manager support this check. >> > > That's fine. The default behavior is that all accesses are valid. > > Shall we make a new transfer function to do this check? >> > > Perhaps, but I think all the logic can be divided between the StoreManager > and GRExprEngine. The StoreManager is responsible for reasoning about what > is valid memory, and GRExprEngine handles loads/stores. This job splitting is OK for me. But does it violates the rule that 'StoreManager does no reasoning'? > What would there be left to put in a specific transfer function? > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
