Messages in this thread | | | Date | Tue, 30 Apr 1996 14:06:30 +0200 | From | Andries.Brouwer@cwi ... | Subject | Re: Database of kernel bugs |
| |
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
| |