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

[Ted Kremenek]

On Nov 5, 2008, at 6:27 PM, Zhongxing Xu <xuzhongxing at gmail.com> wrote:

>
>
> On Thu, Nov 6, 2008 at 10:20 AM, Ted Kremenek <kremenek at apple.com>  
> wrote:
>
> On Nov 5, 2008, at 6:12 PM, Zhongxing Xu wrote:
>
>>
>> On Thu, Nov 6, 2008 at 9:33 AM, Ted Kremenek <kremenek at apple.com>  
>> wrote:
>>
>> On Nov 5, 2008, at 5:24 PM, Zhongxing Xu wrote:
>>
>>> Thoughts?
>>>
>>> Ted
>>>
>>> Sounds reasonable! I remember that there was RegionExtent code.  
>>> Maybe we should pick it up.
>>
>> Right; I scribbled some code for that, but never really implemented  
>> anything real.  I think we just need to establish a "taxonomy" of  
>> extents/sizes, and decide if we need a variant like RegionExtent or  
>> can just use SVals.
>>
>> I think we can use SVals for now and extend to a RegionExtent class  
>> when necessary.
>>
>> Another thing to discuss: what units shall we choose for  
>> representing extent? In bits, bytes, or element numbers? For array  
>> bounds checking, element numbers are the most direct. What other  
>> clients care about the extents?
>
>
> Bits, bytes, number of elements... these are each different  
> abstractions of memory, and different clients will have separate  
> needs.  If we provide a clean interface to go between these units  
> (which could potentially be provided by a RegionExtent class) then I  
> think we (a) can serve more clients more easily and (b) have extra  
> error checking for cases when clients use the wrong units.
>
> Here's one argument for bits.  That's what ASTContext::getTypeSize()  
> and ASTContext::getTypeAlign() return (so there is some consistency  
> there).  Moreover, it is plausible that we have regions over  
> individual bits (e.g., bit fields, bit-level typing).  As long as  
> its consistent I think we're fine.
>
> Yeah. We can represent in bits internally in RegionExtent and  
> provide interface for RegionExtent to convert to bytes or other units.

My thoughts exactly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081105/e775d798/attachment.html>