+lwhsu Things are in motion to bring back the scan-build results on FreeBSD infrastructure, so that it doesn't disappear without notice, again.
On Thu, 2014-04-24 at 13:57:13 +0200, Erik Cederstrand wrote: > Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette <[email protected]>: > > > > In the post that you are replying to, I took issue with two prior assertions > > made by Mark Andrews, specifically (1) that some clang static analysis > > warnings are "false positives" and (2) that elimination some of them was > > "impossible". > > I really wish the reports were online again so we weren't discussing > hypothetical situations here. Ulrich? > > > Sir, does not the following trivial and obvious single line modification > > to the above code eliminate the warning? And does it not do so *without* > > the need for ``considerable effort''? > > > > int x = -1; > > > > I thank you for providing me with the example above, and thus also this > > opportunity to so perfectly illustrate my fundamental point. > > The example I gave is of course trivial to rewrite. It was the shortest > possible example I could think of to illustrate the situation. It was > condensed from a really convoluted if-else case which was not incorrect but > quite difficult to untangle. And yes, it's laudable to rewrite it for the > sake of readability, but it doesn't fix any security issues. > > > As the examples above illustrate, the claim that eliminating the non-helpful > > warnings is ``too hard'' cannot, I believe, be supported by the facts, and > > the (unfortunately widespread) perception that eliminating such warnings is > > ``too hard'' is actually... and not to put too fine a point on it... a > > product more of ignorance or laziness than it is a product of genuine > > difficulty in quieting the unhelpful diagnostics in question. > > As others have pointed out, 'too hard' can also mean 'too hard' to get > someone with commit access to actually commit the patch and accept the risk > of introducing new bugs. Case in point: I contributed this one-liner patch > for ZFS found by Clang Analyzer, adding the __noreturn__ pragma you also > mention: https://www.illumos.org/issues/3363. For 1,5 years, I have been > unable to get anyone from FreeBSD or Illumos to commit it or even review it. > My personal conclusion is that patches to warnings have to fix more severe > issues to get attention. Or in other words, if the warning is a result of the > compiler or analyzer being too stupid, the response will more likely be "fix > the analyzer", and compiler warnings are more likely to be ignored. > > > I'm sorry, you are apparently using some domain-specific terminology with > > which I am not familiar. What exactly is "IPA" and "alpha-remaning"? Do > > these have something do do with SSL? > > Alpha renaming, or α-conversion, is explained here: > http://en.wikipedia.org/wiki/Lambda_calculus > > IPA, or Inter-Procedural Analysis, is explained here: > http://llvm.org/docs/Lexicon.html > > > Erik _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
