<div dir="ltr">On Mon, Oct 6, 2008 at 11:18 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div></div><div class="Wj3C7c"><br><div><div>On Oct 5, 2008, at 6:28 PM, Zhongxing Xu wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>My either idea was to have regions encode minimal information that could be shared amongst different implementations of StoreManager.  I'm not really certain why you wish to add a VarDecl* "pointedBy" field into AnonTypedRegion?  I didn't get around to commenting this class, but AnonTypedRegion is meant to represent a typed chunk of memory; it doesn't have to be pointed by a VarDecl.   It also seems to me that you are using AnonTypedRegion exactly the way BasicStore uses VarRegion.  Isn't it the same thing?  The "Anon" means anonymous; it means there is no name associated with this region.<font color="#888888"></font></div>
 </blockquote><div><br>I use VarDecl* to differentiate AnonTypedRegions. For example, for <br><br>void foo(char* a, char* b) {...},  <br></div></div><br>'a' and 'b' both points to an AnonTypedRegion with type 'char', I just use the VarDecl's of 'a' and 'b' to differentiate these two regions. This is definitely not optimal design, because there might be AnonTypedRegion that are not pointed to by any variable. So it should be discussed. But one thing is sure: we need something to be associated with AnonTypedRegion besides its type and superregion.<br>
 </div></blockquote></div><br></div></div><div>I understand, but this particular use of AnonTypedRegions is exactly the same as VarRegion.  Why not just use VarRegion instead and save the extra QualType?  It also avoids putting the VarDecl* in AnonTypedRegion, since at that point the region is not anonymous.</div>
</div></blockquote><div><br>In RegionStoreManager, I assume pointer parameters points to some anonymous memory region at the beginning of the function. So this AnonTypedRegion is the the region that the parameter points to, not the memory region associated with the parameter itself. So for a function parameter 'char *a', actually I created two regions: one is a VarRegion with VarDecl of 'a' (the region 'R' in my patch), this is the region with 'a' itself. The other is an AnonTypedRegion (the region 'PR' in my patch). This is the region that is pointed to by 'a' (by assumption). This region is really an anonymous region, for we don't know where 'a' points to when we setup the initial store for the function. (In the future interprocedural analysis, we might know.) And to differentiate AnonTypedRegions pointed-at by different parameters, I associate with them the VarDecl of the parameter pointing-at them. Maybe we can have a subclass of AnonTypedRegion to represent such memory region pointed-at by function parameters, and give them VarDecl or other information to differentiate from each other.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div><br></div><div>It seems to me that RegionStoreManager doesn't need to use just one kind of region and one ImmutableMap.  For example, a map from VarDecl* -> VarRegion could be used for mappings from variables to regions, and then other maps could be used for other bindings.  For example, a (MemRegion*, FieldDecl*) -> FieldRegion could be used for field bindings.  A second set of mappings could then be used for region -> value bindings.  In your prototype implementation you have AnonTypedRegion* -> RVal, but one could also just have MemRegion* -> RVal.</div>
</div></blockquote></div><br>My thought is that we don't need any mappings from Decl* to MemRegion*. We only need one mapping from MemRegion* to its stored value RVal. Because once we have the mapping MemRegion* -> RVal, we can calculate the location (MemRegion*) of any name on the fly. So we don't need to store them.<br>
<br>For example, for a VarDecl, its lvalue is always lval::MemRegionVal(VarDecl). For a struct member expression 'p->data', we can first get the superRegion by following p's MemRegion in the store mapping, then get the final region by composite the FieldDecl of 'data' with the MemRegion that p points at.<br>
<br>In summary, we only need to store the Store ( mapping from MemRegion* to RVal), but not the Environment (mapping from names to MemRegion*).<br></div>