git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's cooking in git.git (Oct 2022, #03; Mon, 10)

From
Jeff King <peff@peff.net>
Date
Dec 21, 2022, 23:14 UTC
Message-ID
<Y6OTR2iwcORPsTxz@coredump.intra.peff.net>
In-Reply-To
<92cc457a-d267-d20f-b516-295646b989ca@gmx.de>
On Wed, Dec 21, 2022 at 12:11:54AM +0100, Johannes Schindelin wrote:
Show 8 quoted lines
> > > Is there anybody else who is reading Coverity reports, I wonder.
> > > This one is a clear positive.
> >
> > I doubt it.
> 
> As I mentioned to you previously (e.g. in
> https://lore.kernel.org/git/3896n74p-0r16-866o-r668-70q6pos078n9@tzk.qr/),
> I do have a look at them, usually a closer look during the -rc phases.

Thanks for the reminder. I had a vague recollection that you were pretty negative on Coverity's quality, but you do say pretty clearly there that you'll continue with builds.

That said, I stand by the sentiment that hardly anybody is looking at them. It sounds like it's mostly just you and me.

Show 15 quoted lines
> > My personal fork still has the coverity github-action which I showed
> > last year[1]. We could merge that, but giving access to the project is a
> > minor pain. And of course the full list is full of false positives. One
> > nice thing about coverity is that it marks each defect by date, and
> > tells you how many new ones there are. So when I push up my
> > next+personal branches build, I usually just skim over any new ones it
> > reports. I'd say about 10% of them are actionable.
> 
> That 10% number does not match up with my experience.
> 
> In the v2.39.0-rc period, I looked through over a hundred new issues.
> Pretty much all of them were strvec/strbuf false positives, and even the
> remaining ones were not actionable. (I typically glance over leaks such as
> the one you reported, in favor of focusing on bugs that may cause crashes
> or other serious problems.)

My counting method may be a bit more generous to Coverity. I build 'next' (plus my local topics) every day or three, and get an email from Coverity if there's anything new. If so, I look at it. So I'm counting "times I got an email and looked" as the denominator, and the numerator is "there was at least one useful warning". So that skips some useless ones that appear along side useful ones.

I'm not sure how you saw a hundred new issues, though. My dashboard has 10 unresolved issues total since the beginning of September, which is before 2.38 was released, and I think I sent 2 fixes since then (which are not counted, since they're now resolved, so 2/12).

I do think it would be less noisy if we could somehow convince Coverity that yes, strbuf really does NUL-terminate the result. But I haven't wanted to sink time into figuring out how to annotate it.

-Peff
Previous: Johannes SchindelinNext: Ævar Arnfjörð Bjarmason
Message 6 of 8 in “What's cooking in git.git (Oct 2022, #03; Mon, 10)”
  1. Junio C HamanoOct 10, 2022
  2. Jeff KingOct 11, 2022
  3. Junio C HamanoOct 11, 2022
  4. Jeff KingOct 11, 2022
  5. Johannes SchindelinDec 20, 2022
  6. Jeff KingDec 21, 2022
  7. Ævar Arnfjörð BjarmasonDec 22, 2022
  8. Jeff KingDec 22, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.