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