<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 9, 2009, at 6:02 PM, Zhongxing Xu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; ">2009/11/10 Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>>:<br><blockquote type="cite">Hi Zhongxing,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'm not convinced this is a good check, as there are a bunch of valid cases<br></blockquote><blockquote type="cite">where you would do this.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">First, I think this has the potential to flag a bunch of false positives on<br></blockquote><blockquote type="cite">OO code, like Gtk+. One thing I've noticed is that some C code tries to<br></blockquote><blockquote type="cite">compute the start of the object from the address of a field (using<br></blockquote><blockquote type="cite">offsetof). That seems reasonable to me, and appears frequently in certain<br></blockquote><blockquote type="cite">kinds of code bases.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Second, consider C++ iterators. For example, in our own code base we might<br></blockquote><blockquote type="cite">write:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> SourceRange R = ...<br></blockquote><blockquote type="cite"> foo(&R, &R+1);<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">where the '&R+1' represents the "end" iterator. This is a case where a<br></blockquote><blockquote type="cite">variable is treated as an array of size 1. We'd flag a warning every time<br></blockquote><blockquote type="cite">this idiom appears. That doesn't seem useful.<br></blockquote><br>Sounds reasonable. If this checker cause many false positives I'd like<br>to remove it.<br></span></blockquote><div><br></div><div>Okay. Let's grind it through real code and see what we get.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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><blockquote type="cite"><br></blockquote><blockquote type="cite">It seems to me that buffer overflow checking, where an actual load/store is<br></blockquote><blockquote type="cite">done on a invalid offset, will catch more real issues. Are there cases that<br></blockquote><blockquote type="cite">we will miss with buffer overflow checking that this one will cover?<br></blockquote><br>We don't have a suitable scheme to represent the location of<br><br>int x;<br>&x + 1;<br><br>Shall we create an element region with offset 1 and super region of a<br>scalar type?<br></span></blockquote><br></div><div>Yeah, it seems like ElementRegion(VarRegion(x), 1) would represent that location just fine, even that loading/storing from that address is bad.</div></body></html>