|
From: Nicholas N. <nj...@ca...> - 2004-01-06 06:21:42
|
On Mon, 5 Jan 2004, John Reiser wrote:
> > As with all free software, you get out what you put in.
>
> I put in test cases, I get out bugs -- enough to demonstrate that memcheck
> has a ways to go before I should rely on it to check non-test code.
Memcheck produces false positives and false negatives. This will always
be the case, because the method it uses isn't sound or complete, and the
implementation will always have imperfections. (And I agree that the bugs
you mention, particular the lack of checking on scalar syscall arguments,
should be looked at.)
However, I don't see why one shouldn't use Memcheck on non-test code:
- If it produces false positives, as long as the number is small enough
that they don't become a distraction -- and I think experience shows
that this is true for Memcheck -- one can check them, determine their
falsehood, and suppress them.
- As for producing false negatives, the only problem I can see with this
is if someone assumes that when their programs passes Memcheck without
errors, that it is totally bug-free with respect to memory errors. I
don't imagine this is common, and it is not the case with you John --
you are clearly aware of Memcheck's shortcomings.
I can understand why you might not trust a compiler that you knew had
certain bugs -- because you are relying on blemish-free output. But
Memcheck is a different sort of program, where the output doesn't have to
be blemish-free for it to still be useful. So I don't understand why
relying on it would be a bad thing. Perhaps you could elaborate further?
N
|