On 09.08.2010 18:45, Antti Kantee wrote: > 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.
Does not seem to... >> - 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 ;) Keep looking down a bit :) IMHO, all the rest are real bugs, and concern kernel directly. It affects parts I am sadly not experienced enough with, so I wouldn't commit without prior approval. Note also that I applied the spatch against sys/; the rest of src could get a scan. But I would prefer to look for other static analyzers first, perhaps there are more suitable (and faster) ones. > 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. This requires maintenance, and having multiple tools each raising false positives can only get semi-automated. Besides, avoiding false positive may get the opposite result, masking true ones. -- Jean-Yves Migeon jeanyves.mig...@free.fr
