[cfe-commits] [PATCH] Set region size in GRRegionVals transfer function
xuzhongxing at gmail.com
Fri Nov 7 00:44:12 PST 2008
On Fri, Nov 7, 2008 at 4:05 PM, Ted Kremenek <kremenek at apple.com> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits