On Fri, Nov 7, 2008 at 4:05 PM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
> > On Nov 6, 2008, at 11:54 PM, Zhongxing Xu wrote: > > 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'? >> >> > By "reasoning", I mean "reasoning about extents". > > Perhaps we should talk more about what the requirements would be for an > out-of-bounds checker before deciding where its implementation pieces should > be. > > From what I can tell, an out-of-bounds check has three components: > > (1) a location L, which is an offset within a region X > (2) the extent of region X > (3) some logic to determine if the location L is outside the extent of > region X > > We need to decide if we currently represent (1) for the interesting cases > that we are initially interested in going after. I have some difficulty to understand this sentence. I think a we will just get a location MemRegionVal with a out-of-bound ElementRegion, returned by getLValue(). And nobody is aware of its illegality at that time. > Right now locations are modeled using SVals. > > I think the consensus is that (2) is managed by StoreManager. > > For (3), we need to decide where this decision logic would go. My guess > was GRExprEngine, which would issue a series of "Assume" calls to the > ConstraintManager to determine if the offset of L exceeded the extent X. > I'm not sure exactly what that would look like. > I'll try to scratch an implementation to see what indeed we need.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
