Re: Using coccinelle for (quick?) syntax fixing

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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.migeon%free.fr@localhost