[cfe-commits] r61147 - in /cfe/trunk: lib/Analysis/CFRefCount.cpp test/Analysis/uninit-vals-ps.c

[Ted Kremenek]

On Mar 10, 2009, at 9:31 PM, Zhongxing Xu wrote:

>
> CFStringRef rdar_6451816(CFNumberRef nr) {
>   CFStringEncoding encoding;
>   // &encoding is casted to void*.  This test case tests whether or  
> not
>   // we properly invalidate the value of 'encoding'.
>   CFNumberGetValue(nr, 9, &encoding);
>   return CFStringConvertEncodingToIANACharSetName(encoding); // no- 
> warning
> }
>
> We would have to invalidate a TypedViewRegion(void*,  
> VarRegion('encoding')). Then StoreManager should canonicalize it to  
> VarRegion('encoding').
> Does that mean we have a new rule for canonicalization of discarding  
> void* typed view besides discarding typedefs? That is, void* typed  
> view is another kind of 'sugar' like typedefs?
>

I thought about this more, although I'm still mulling the details.

Yes we would pass TypedViewRegion(void*, VarRegion('encoding')) to the  
transfer function for CFNumberGetValue.  That transfer function would  
then try to "cast" that region to the appropriate type for the value  
it stores.  The StoreManager could determine if that cast is valid; if  
it casts to the same type as VarRegion('encoding') then we bind a new  
symbol directly to VarRegion.  Otherwise we issue a path-sensitive  
type error.

Here is the API documentation for that CFNumberCreate:

http://developer.apple.com/documentation/CoreFOundation/Conceptual/CFDataFormatting/Articles/dfCreatingCFNumberFormatters.html

Basically, we need to come up with what a "view" means and when is it  
legal.  I think "views" are legal when one is casting to a more  
specialized type (other checks need to determine if this downcast is  
legal).  Upcasts should just strip views away.

There is also the issue of what is the "foundational type" of a piece  
of memory (that is the memory should essentially always be treated  
this way).  For VarRegion, the foundational type of that memory chunk  
is given by VarRegion::getRValueType().  For SymbolicRegions, perhaps  
we want some symbolic regions to have foundational types and others  
not (e.g., raw chunks of memory).  We could potentially distinguish  
between the two using two different SymbolicRegion classes, for example.