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

Ted Kremenek kremenek at apple.com
Wed Nov 5 18:20:27 PST 2008

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

More information about the cfe-commits mailing list