[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:

> This scheme looks great to me! Two points:
>
> a. Symbolic regions may have types. For example: void foo(char* buf)  
> {...}. 'buf' => SymbolicRegion with type char*

There is no inherit reason to treat parameters this way.  We could  
instead do:

  'buf' => TypedViewRegion(char*, SymbolicRegion)

This binding can also be done lazily.  We just return a  
loc::MemRegionVal instead of a loc::SymbolVal (the latter should  
probably go away anyway).

>
> b. Applying the scheme to your test case:
>
> // <rdar://problem/6451816>
> typedef unsigned char Boolean;
> typedef const struct __CFNumber * CFNumberRef;
> typedef signed long CFIndex;
> typedef CFIndex CFNumberType;
> typedef unsigned long UInt32;
> typedef UInt32 CFStringEncoding;
> typedef const struct __CFString * CFStringRef;
> extern Boolean CFNumberGetValue(CFNumberRef number, CFNumberType  
> theType, void *valuePtr);
> extern CFStringRef CFStringConvertEncodingToIANAC
> arSetName(CFStringEncoding encoding);
>
> 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').

Good observation.

>
> Does that mean we have a new rule for canonicalization of discarding  
> void* typed view besides discarding typedefs?

I don't think so.

> That is, void* typed view is another kind of 'sugar' like typedefs?

No.  void* is not sugar; it literally means treat this memory as  
untyped.

In reality 'CFNumberGetValue' casts the void* to the appropriate  
pointer type and then does the store.  So the "effect" of the function  
call is to bind a new symbol to TypedViewRegion(someType,  
SymbolicRegion(...)), where the symbol will match the type of  
'someType'.  someType is argument dependent, but that should be  
captured in the "summary" for CFNumberGetValue.  While this summary  
will be hard-coded, in the future inter-procedural analysis should  
handle this automatically.

What this means is that the logic for that check needs to be updated  
to conform (should we adopt it) to the new design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090311/75b10015/attachment.html>