[cfe-commits] r59957 - in /cfe/trunk: include/clang/Analysis/PathSensitive/Store.h lib/Analysis/GRExprEngine.cpp lib/Analysis/RegionStore.cpp

[Zhongxing Xu]

On Tue, Nov 25, 2008 at 8:28 AM, Ted Kremenek <kremenek at apple.com> wrote:

>
> On Nov 24, 2008, at 4:17 PM, Zhongxing Xu wrote:
>
> On Tue, Nov 25, 2008 at 3:03 AM, Ted Kremenek <kremenek at apple.com> wrote:
>
>> Hi Zhongxing,
>>
>> Why use the GDM to represent the byte extent of an AllocaRegion instead of
>> storing it directly in the region object itself?  I don't think it's
>> necessarily a bad idea; I'm just curious about the overall design.
>
>
> I don't have a definite reason for this. I feel that:
>
> - The extent is not a necessary property of AllocaRegion (or the necessity
> has not showed). If we make it part of the AllocaRegion, that would require
> all clients provide an extent when creating the AllocaRegion.
>
>
> Just to clarify, what do you mean by "clients?"  Different implementations
> of StoreManager?
>

Yes, it should be StoreManagers. But in a broader sense, anything that wants
an AllocaRegion created are burdened.


>
> - Decoupling the extent of the dynamically allocated region provides more
> flexibility. Consider a MallocRegion, whose extent may be changed by a later
> realloc(). But its store bindings may not change. In that case, we can only
> modify the extent mapping of it.
>
>
> Makes sense.
>
> - If later we find the extent is an essential property of AllocaRegion, we
> can add it back.
>
>
> Absolutely.  I wasn't arguing that we change it.  All of this sounds good
> to me.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081125/05767a0e/attachment.html>