On Mon Aug 09 2010 at 18:19:28 +0200, Jean-Yves Migeon wrote: > > That said, if $someone can produce a set of rules which showably find > > bugs in NetBSD code and do not produce a lot of false positives, I'm > > very interested in seeing nightly runs. > > Alright, let's get a bit more practical. Warning: patch may not apply > cleanly, and I am working with a "month-old" src: > > - logical not with bitwise "&" (attached: notvsand.diff) > > This one should be checked, I am not familiar with this code.
Those definitely look fishy. I'm surprised gcc doesn't give a warning. > - more serious: NULL check then dereference (attached: nullderef.diff) > > IMHO, the last ones would be easier to spot with "if (foo == NULL)..." > instead of having "if (!foo)..." Clarity does help (guess it did not for > the other half, anyway :/ ) Well, at least the first one is under #ifdef __FreeBSD__, and would panic anyway already in malloc ;) But, sure, it's always useful to check error branches are not a highly complex call to uvm_fault(). > > ... especially if there are no TAILQ false positives ;) > > Only true negatives with that one :p > > Purpose was to gather opinions (if it got wildly rejected, I would have > stop doing anything with it now). Note that I view coccinelle more like a > tool making rototilling easier than full blown static analyzer; there are > probably better ones out there (clang). IIRC, there were some private discussions earlier (year or so ago?) and it was suggested that rototills should accompany a public spatch. But given that in practise applying the spatch is usually a combination of using spatch, sed, etc., there would need to be accompanying documentation too. Anyway, someone needs to work out the details and drive the issue. I think your examples are useful to run every now and then in a static analyzer capacity. Just because there are "better" ones, doesn't mean others are obsolete, especially if the results are different.
