<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 10, 2009, at 9:31 PM, Zhongxing Xu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">This scheme looks great to me! Two points:<br><br>a. Symbolic regions may have types. For example: void foo(char* buf) {...}. 'buf' => SymbolicRegion with type char*<br></span></blockquote><div><br></div><div>There is no inherit reason to treat parameters this way. We could instead do:</div><div><br></div><div> 'buf' => TypedViewRegion(char*, SymbolicRegion)</div><div><br></div><div>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).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br>b. Applying the scheme to your test case:<br><br>// <<a href="rdar://problem/6451816">rdar://problem/6451816</a>><br>typedef unsigned char Boolean;<br>typedef const struct __CFNumber * CFNumberRef;<br>typedef signed long CFIndex;<br>typedef CFIndex CFNumberType;<br>typedef unsigned long UInt32;<br>typedef UInt32 CFStringEncoding;<br>typedef const struct __CFString * CFStringRef;<br>extern Boolean CFNumberGetValue(CFNumberRef number, CFNumberType theType, void *valuePtr);<br>extern CFStringRef CFStringConvertEncodingToIANAC<div id=":17" class="ii gt">arSetName(CFStringEncoding encoding);<br><br>CFStringRef rdar_6451816(CFNumberRef nr) {<br> CFStringEncoding encoding;<br> // &encoding is casted to void*. This test case tests whether or not<br> // we properly invalidate the value of 'encoding'.<br> CFNumberGetValue(nr, 9, &encoding);<br> return CFStringConvertEncodingToIANACharSetName(encoding); // no-warning<br>}<br><br>We would have to invalidate a TypedViewRegion(void*, VarRegion('encoding')). Then StoreManager should canonicalize it to VarRegion('encoding').<span class="Apple-converted-space"></span></div></span></blockquote><br></div><div>Good observation.</div><div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div id=":17" class="ii gt"><span class="Apple-converted-space"> </span><br>Does that mean we have a new rule for canonicalization of discarding void* typed view besides discarding typedefs?</div></span></blockquote><div><br></div><div>I don't think so.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div id=":17" class="ii gt"> That is, void* typed view is another kind of 'sugar' like typedefs?<br></div></span></blockquote></div><br><div>No. void* is not sugar; it literally means treat this memory as untyped.</div><div><br></div><div>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.</div><div><br></div><div>What this means is that the logic for that check needs to be updated to conform (should we adopt it) to the new design.</div></body></html>