Hi Kamil, > I meant the public reports on this mailing-list like the one that Ondrej > sent. > As gnulib is embedded in multiple RPM packages of Fedora/RHEL, such reports > are going to come periodically until you change your attitude to handling > false positives upstream. > ... > The problem is that this is a duplicated effort to your > reviews of Coverity results upstream.
So far the number of these reports has been small and manageable. When it gets higher, we may very well use your 'csdiff' package. Is there, besides this package, also a "best practices" document how to use it (e.g. where to store the results of previous run, how to map categories to priorities, etc.)? > And many downstream consumers have to > duplicate the effort as well. Downstream consumers can exclude the gnulib-copied directories using the 'csgrep' program, AFAIU? > The main advantage of code improvements and inline code annotations is that > they travel together with the source code when the files are moved in the > source tree, across the projects, or embedded into other projects. All the > downstream consumers can consume these improvements at no additional cost. True. But it clutters up the source code. For tools that produce 5-10 times more false reports than good reports, I wouldn't do this. Things are different for tools or warning categories which, on average, produce > 75% good reports (like, specific warnings included in "gcc -Wall"). Bruno
