<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 23, 2012, at 5:28 AM, Jordy Rose wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Feb 23, 2012, at 0:36, Anna Zaks wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 18, 2012, at 5:34 AM, Jordy Rose wrote:<br></blockquote><blockquote type="cite"><br></blockquote><font class="Apple-style-span" color="#690303"><br></font><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+// Rely on the CString checker evaluation of the strcpy API to convey that the result of strcpy is equal to p.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+void symbolLostWithStrcpy(char *s) {<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ char *p = malloc(12);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ p = strcpy(p, s);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ free(p);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+}<br></blockquote></blockquote></blockquote><br>Yes, I see that there was a false positive here. But it seems that MallocChecker directly depends on the evaluation of /every/ alias-returning function. The string functions happen to be fairly ubiquitous and present in the same library, so I can see that it might be worth special-casing them, but I personally don't consider understanding strcpy to be an /inherent/ feature of MallocChecker. If the analyzer in general doesn't know about string functions, you shouldn't be surprised when MallocChecker doesn't know about the string functions either.<br></div></blockquote><br><div>I don't fully get your point here.. I think implementing domain specific knowledge in the checkers rather then the analyzer core is the right solution. Reasoning about non-malloc related functions makes the Malloc checker more powerful. -> Setting the dependency between the two is the way to solve the problem.</div><div><br></div><div>Ideally, CStringBasic should only include the function evaluation logic (and skip the CStringNullArg warning). It's a cleanup, which we should definitely do. But other then that, I do not see issues with this solution.</div><br><blockquote type="cite"><div>Then again, since it doesn't cost /that/ much, maybe this is a case of "Clang should Do The Right Thing" by default. So I withdraw my objection.<br><br>Jordy<br><br></div></blockquote></div><br></body></html>