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

[Zhongxing Xu]

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