[cfe-commits] [PATCH] A tentative implementation of RegionStoreManager

[Ted Kremenek]

On Oct 6, 2008, at 9:10 PM, Zhongxing Xu wrote:

> A new patch attached. In this patch, we introduce a  
> AnonPointeeRegion to represent the assumed pointee of parameter or  
> global pointers.
>
> Another scheme: we assume nothing about parameter or global  
> pointers, just give them a symbolic value, as we do in the  
> BasicStore. Then we will not bother this AnonPointeeRegion and the  
> unknown MemSpaceRegion. What do you think of this?
> <pointeeregion.patch>

Having an AnonPointeeRegion seems like a great first step, although I  
think in the long term just have symbolic values for globals and  
parameters has some appeal as well.  In the case of symbolic values,  
what happens in cases like the following:

void foo(int *p, int *q) {
   *p = 1;
   *q++;
}

Does 'p' bind to a symbolic value upon entry, and after "*p" we lazily  
create a region for it and then bind the value '1' to that region?   
What about 'q'?  If we determine that 'p' and 'q' alias each other, do  
we unify their regions/symbols?  I believe that thinking about  
questions like these help make the design choices a little clearer.

I'm not looking for a perfect solution, but aliasing relationships are  
something we need to consider.  Most bug-finding tools assume that  
pointers of the same type are not aliased because this is the case 90%  
of the time.  We can also lazily "assume" aliasing relationships, just  
like we do with pointers that are potentially null.

For example, GRExprEngine makes no assumptions about the nullness of  
'p' upon entry to the function, and records an "implicit null  
dereference" to 'p' in the case that 'p' was null:

void (int* p) {
   *p = 1;
}

Clients can then go over the analysis results and look for implicit- 
null dereferences; if the client knows that a parameter value could be  
null, we have the opportunity to flag a warning.  This is exactly what  
we do in CheckNSError.cpp.

Similarly, aliasing relationships could be handled the same way, with  
bugs on paths stemming from conservative reasoning about aliases being  
ranked lower (or suppressed than other bugs) until we know that 'p'  
and 'q' could actually alias each other (for example).