Re: What's cooking in git.git (Oct 2021, #02; Wed, 6)

From: Jeff King <peff@peff.net>
Date: Oct 8, 2021, 03:55 UTC
Message-ID: <YV/BMkZrj4xQyvUL@coredump.intra.peff.net>
In-Reply-To: <YV5yi+AejPGO9qOi@nand.local>

On Thu, Oct 07, 2021 at 12:07:39AM -0400, Taylor Blau wrote:

Show 9 quoted lines

> On Wed, Oct 06, 2021 at 10:38:18PM -0400, Jeff King wrote:
> > The reason for that is that I didn't find it by inspection; I've started
> > running my personal builds through coverity. It wasn't too bad to set up
> > with a GitHub Action, like so:
> >
> > [...]
> 
> It looks like this would never cause the build to fail, but is merely
> responsible for sending any warnings off to Coverity's UI?

Sort of. They basically wrap the "make" invocation to intercept "cc". My understanding is that their faux-compiler is mostly about gathering data about the code. That gets stuffed into a tarball and uploaded to their servers, where the real analysis happens.

It's very black-box, which I don't love. But in my experience it produces by far the most useful static-analysis output of any tool I've seen.

Show 14 quoted lines

> > There are tons of existing warnings, many of which are false positives.
> > But it keeps track of which problems are new, and emails out a summary
> > of only the new ones (which is how I saw the leak here, which just hit
> > next). I don't care all that much about leaks here (we have other
> > techniques for finding them), but when Stefan used to do regular
> > coverity builds in the past, it routinely found useful errors.
> 
> I'm generally pessimistic about tools like Coverity, but I share your
> experience that Coverity warnings are actually pretty high quality. Or
> at least they have a high enough signal-to-noise ratio that it makes
> them worth looking through.
> 
> So I would be happy to have forks of GitHub have fewer barriers to use
> this tool.

OK. I'll see if I can clean up the patch a bit.

-Peff