bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tar + cpio - covscan issues


From: Kamil Dudka
Subject: Re: tar + cpio - covscan issues
Date: Fri, 16 Apr 2021 10:02:39 +0200

On Thursday, April 15, 2021 10:30:14 PM CEST Paul Eggert wrote:
> On 4/15/21 1:07 PM, Kamil Dudka wrote:
> > People maintaining their own medium-size projects can easily play with
> > this. I am in a different situation when I need to scan 3700 distinct
> > projects and approx. 480 million lines of code with more or less the same
> > manpower ;-)
> I can appreciate the amount of work it takes to maintain all that
> scanning. Still, we have to be careful here not to let the tail wag the
> dog. The false-alarm rate from Coverity is too high for us to install
> patches needed only to pacify Coverity. Similarly for GCC with all its
> warning flags enabled.
> 
> > we would have to maintain such exclusion lists per project.
> 
> My guess is that overall this would be less work, than the work of
> installing and reliably maintaining patches that pacify all combinations
> of Coverity and 'gcc -Wall -Wextra -Wetc' flags used by any downstream
> projects, without breaking or slowing down anything in any project. (But
> of course messing with exclusion lists would be work that you'd have to
> do, rather than us. :-)

Not only me.  This affects all downstream consumers of gnulib-based projects.

On a second thought, excluding gnulib source code from static analysis is not 
an option for us anyway.  We use such exclusion lists for unit tests that run 
in our test environment but that are not distributed to customers.

gnulib is a different case because some parts of its code run in production 
environment of our customers.  Red Hat certifies the software and we cannot 
say that we skipped static analysis of gnulib because upstream already did it.  
We have to (re)verify the software that we distribute in the end.

I am reading your responses as "upstream is not going to change anything".  We 
will have to find some ways to deduplicate and record these false positives on 
our side then.

Kamil





reply via email to

[Prev in Thread] Current Thread [Next in Thread]