[cfe-commits] [PATCH] Set region size in GRRegionVals transfer function
xuzhongxing at gmail.com
Wed Nov 5 18:27:07 PST 2008
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:
>> 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
> 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
> 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
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...
More information about the cfe-commits