Re: Database of kernel bugs

Andries.Brouwer@cwi.nl
Tue, 30 Apr 1996 14:06:30 +0200


On Mon, 29 Apr 1996 Andries.Brouwer@cwi.nl wrote:

> No, 99.9% is junk - not things that should be fixed in the kernel,
> but things that should be suppressed in the output.
>
> Polishing the kernel source in such a way that it survives stricter testing
> than gcc does would be useful indeed. But ospc cannot be used for that
> purpose, since it is not available, and so far only has produced garbage.
> I have played a little bit with lclint yesterday, it is at least available,
> but it is not up to the task either - it gets easily confused by gcc-isms.

So email Derek at Knowledge Software (derek@knosof.co.uk) and tell him
what is being unnecessarily flagged and why it's unnecessary. He seems
like a reasonable guy who'd be quite willing to listen to you if you want
to bother making suggestions.

I think I did, maybe a few weeks ago.

Personally, I think it's quite nice of him to go to all the trouble he has
to run the kernel through his company's product. If you give him a little
constructive criticism, I'm sure he'll listen, and then he'll make a
(hopefully small) output file of actual bugs. As it is, he's got a large
output file, a lot of which are not actually bugs, but since no one has
told him about the stuff he's unnecessarily flagging, he doesn't know to
fix the problem.

Well, in fact such a process is an interactive one.
One looks at the output, understands why a certain construct is flagged,
either decides that it is quite OK, and adds a flag to the checker
not to complain about this type of thing again, or goes through the source
and fixes that particular type of flaw. In order to do this, one needs
access to this checking software - it would be run many times, several
hundred times for example. Initially this a lot of work, and it catches
very few real bugs, but once it has been done, the source satisfies
slightly higher standards, and it is a small effort to keep it that way.
But this requires permanent access to the checking software.
As I understand it, ospc is not available, so cannot be used
for this purpose. One single run, on a single kernel, with a 7MB file
with error messages, is not useful.

Andries