<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 19, 2013, at 8:56 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Thu, Jul 18, 2013 at 5:26 AM, John Smith <<a href="mailto:lbalbalba@gmail.com">lbalbalba@gmail.com</a>> wrote:<br><blockquote type="cite">On Mon, Jul 15, 2013 at 6:39 PM, Richard <<a href="mailto:legalize@xmission.com">legalize@xmission.com</a>> wrote:<br><blockquote type="cite"><br>Sylvestre Ledru wrote<br><blockquote type="cite">Hello,<br><br>After setting an automatic code coverage tool [1], I just plugged an<br>automatic scan-build on the LLVM toolchain:<br><br><a href="http://buildd-clang.debian.net/scan-build/">http://buildd-clang.debian.net/scan-build/</a><br></blockquote><br>So... this seems like something I could contribute. Small, isolated<br>fix with an automated way of knowing when I've fixed it.<br><br>However, I don't want to duplicate work being done by someone else as<br>I've just subscribed to the list. Are these being turned<br>automatically into bug tickets? Do I just "claim" some of these and<br>then submit a patch?<br><br></blockquote>I see no one has answered this one yet, so ill have a go here:<br><br>I doubt the report is 'automagically' turned into bug reports, or that<br>(if even possibly, certainly requiring more skills that I have) it<br>would even be desirable. Part of the process is to determine if you<br>are dealing with a genuine bug or a false positive. And as icing on<br>the cake, if it is a false positive, maybe even a modification of the<br>checker to prevent it from generating similar false positives in the<br>future.<br></blockquote><br>The nice part about bugs in the LLVM database is that they would<br>either be bugs in the code (true positives) or bugs in the analyzer<br>(false positives) - so either way the bug could be used to track the<br>resolution. (assuming that there's no "acceptable false positive"<br>without some kind of suppression mechanism, which seems like a<br>reasonable goal - if a project can't hold itself at/towards "clean"</div></blockquote><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">that seems like a problem)<br></div></blockquote><div dir="auto"><br></div>I agree that it would be great if we could get to a state where LLVM+clang+.. codebase is static analyzer warnings free. </div><div>I am not sure that automated bug filing for each reported issue is the best approach. Many false positives ("analyzer is wrong") issues will be dups of one another. Also, if we resolve most of the reported issues, it would be much easier to keep the project analyzer-warning clean going forward.</div><div><br></div><div>Richard, Here are some suggestions on how one could deal with the reported issues:</div><div>1) If an issue looks like a real bug in the codebase, prepare a patch to fix it and get it reviewed by someone familiar with the code.</div><div dir="auto"><br></div><div dir="auto">2) Some of the reports might not be bugs you could trigger, but point at code that might benefit from restructuring, which would also suppress the analyzer report. If that is an acceptable solution, we should go for it.</div><div dir="auto"><br></div><div dir="auto">3) The last bucket are the real false positives that cannot be fixed with code restructuring. Some of these might be easier to fix in the analyzer, some might be very difficult to fix. Static analyzer is not a zero false positives tool. Our false positive suppression mechanism is currently very primitive, but it exists. It's the <font color="#222222">__clang_analyzer__ macro, which we could use if we are going for analyzer warning free codebase. Another approach would be to built up on the CmpRun.py script, which can allow us to compare issues from different runs and report the diff, so after you fix all the real bugs, you'd expect the diff to not include new issues. the main benefit is that you don't need to change the codebase. However, bringing that up would require much more effort. One challenge, for example, is to compare issues on an evolving codebase; the solution we use now is very primitive. (Other people from the community might also have an opinion on what is an acceptable approach here.)</font></div><div dir="auto"><br></div><div dir="auto">You can find a bit more info on how to deal with #2 and #3 in:</div><div dir="auto"><a href="http://clang-analyzer.llvm.org/faq.html">http://clang-analyzer.llvm.org/faq.html</a></div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Anna.</div><div dir="auto"><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>So I think it might be worth considering an auto-filing system, if<br>anyone wanted to spend the time to do so. (one issue might be figuring<br>out how to not file the same issues again on future runs - maybe even<br>detect when they've been fixed </div></blockquote><div dir="auto"><br></div><div dir="auto">This auto-detection could be built on top of the result comparison script (see above). You'd probably need a database somewhere to store these, possibly a UI for people to mark the resolution of these.</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">(though that would be hard - since the<br>code might change so it doesn't trigger the warning anymore, but if<br>it's a false positive that doesn't mean the bug in the analyzer has<br>been fixed - but if someone's not looked at/resolved the bug, maybe<br>it's worth just resolving the bug as no-repro & moving on))</div></blockquote><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite"><br>I guess the best way to go would be announcing on this list that youre<br>looking into a certain class of bugs in the report and ask if anyone<br>else is doing that already. If noone answers, I assume it would be<br>safe to claim the bug(s) and start working<br><br><br>Regards,<br><br><br>John Smith.<br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br></blockquote>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></div></blockquote></div><br></body></html>