<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 29, 2009, at 9:15 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: 0; "><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; "><br class="Apple-interchange-newline">Added: cfe/trunk/test/Analysis/rdar-6541136.c<br>URL:<span class="Apple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/rdar-6541136.c?rev=63347&view=auto" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/rdar-6541136.c?rev=63347&view=auto</a><br><br>==============================================================================<br>--- cfe/trunk/test/Analysis/rdar-6541136.c (added)<br>+++ cfe/trunk/test/Analysis/rdar-6541136.c Thu Jan 29 18:08:43 2009<br>@@ -0,0 +1,20 @@<br>+// clang -verify -analyze -checker-cfref -analyzer-store-basic %s<br>+<br>+struct tea_cheese { unsigned magic; };<br>+typedef struct tea_cheese kernel_tea_cheese_t;<br>+extern kernel_tea_cheese_t _wonky_gesticulate_cheese;<br>+<br>+// This test case exercises the ElementRegion::getRValueType() logic.<br>+// All it tests is that it does not crash or do anything weird.<br>+// The out-of-bounds-access on line 19 is caught using the region store variant.<br>+<br>+void foo( void )<br>+{<br>+ kernel_tea_cheese_t *wonky = &_wonky_gesticulate_cheese;<br>+ struct load_wine *cmd = (void*) &wonky[1];</blockquote><div><br>This is like an ill use of the type system. What do you think we emit a warning instead of following it.<br>That is, we emit a warning when the array region does not have array type or pointer type.</div></span></blockquote></div><br><div>Yes this is really gross code. It actually contains more stuff than the original test case I looked at just to see if the analyzer would crash. The original test case was basically:</div><div><br></div><div><div> kernel_tea_cheese_t *wonky = &_wonky_gesticulate_cheese;</div><div> struct load_wine *cmd = (void*) &wonky[1];</div><div><br></div></div><div>Let's just consider this for a moment. While the out-of-bounds access looks wrong in all cases, aside from the out-of-bounds access it may be "okay." Consider the following possible definition of struct load_wine:</div><div><br></div><div>struct load_wine {</div><div> struct tea_cheese x;</div><div> ...</div><div>};</div><div><br></div><div>In this case, it is okay to cast a 'struct tea_cheese*' to a 'struct load_wine*'. This kind of pattern appears a lot in the Gtk+ code (and other C libraries) to simulate object-oriented programming and inheritance.</div><div><br></div><div>The problem here is that we don't have the definition of 'struct load_wine'. If we did, we could do some extra type checking (as you suggest). In this case, we don't, so what do we do?</div><div><br></div><div>As for:</div><div><br></div><div><div> char *p = (void*) &wonky[1];</div><div> *p = 1;</div><div><br></div><div>Yes that is really gross. What should we do here? This is technically an out-of-bounds memory write (which we don't flag because of the abuse of the type system), but as you said it is an abuse of the type system. With our path-sensitive type information in the RegionStore objects perhaps we can flag a more lucid warning? On the other hand, assuming that &wonky[1] is valid (say wonky was an array), we're just writing '1' to the first byte of the 'magic' field. The rabbit hole goes arbitrary deep.</div></div></body></html>