On 07/02/2015 05:30 AM, Michal Privoznik wrote:
On 01.07.2015 16:03, John Ferlan wrote:
>
I'm picking a random Coverity thread to express my latest thoughts on
this. I'm not trying to say the problems I'm raising are necessarily
introduced here in this patch set.
We've seen quite a lot of false positives lately. I'm not familiar with
coverity, but does it have a suppress file, something like valgrind has?
In valrgind, one can enumerate stacktraces that would be reported, but
has been investigated by a developer and therefore are known to be okay.
If coverity would have something like that I think should utilize it.
We've poisoned our code with sa_assert()-s, dummy coverity comments,
etc. If we can keep our code clean, that'd be nice. I guess I'm okay
with having the coverity suppress file in the repo - we have the
valgrind one already.
Not sure how a Coverity suppress file works, but if I have some cycles
I'll look into it. However, if it's susceptible to code motion, then it
may not be worth it... The last time I looked (almost 2 years ago) at
the valgrind suppress file it had some stale chunks, but it also had a
decent way to "ignore" certain traces.
In any case, I'll look into removing existing sa_assert()'s... As a
test, I removed the definition and reran a build to find areas that
currently "require" it. I think of the 15 or so "issues", perhaps 1 or
2
could go away with some refactoring.
Oh, and for false positives maybe we should file a bug report against
coverity (if possible).
That's generally the more difficult part especially when it comes to
replicating the build environment (including .gnulib) in a "small
module" as any good developer would ask for when someone claims your
product has a defect. Also as I pointed out before - those aren't
necessarily Coverity defects - it's pointing out valid concerns which
take human intervention to determine whether they are a problem or not.
John