On Thu, Nov 6, 2008 at 10:20 AM, Ted Kremenek <[EMAIL PROTECTED]> wrote:
> > On Nov 5, 2008, at 6:12 PM, Zhongxing Xu wrote: > > > On Thu, Nov 6, 2008 at 9:33 AM, Ted Kremenek <[EMAIL PROTECTED]> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
