[cfe-commits] [PATCH] Set region size in GRRegionVals transfer function

[Zhongxing Xu]

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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081107/e7ea5267/attachment.html>