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

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

 



On Fri, Oct 08, 2021 at 09:51:33AM +0200, Johannes Schindelin wrote:

> > 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.
> 
> It is pretty black box, but I have to disagree that the static analysis
> output is very useful. The majority are false positives about
> strbuf/strvec type usage of a static, fixed-size array that is dynamically
> replaced by a dynamically-allocated array. Coverity misses that subtlety
> and reports out-of-bounds accesses.

Yes, I remember skipping past quite a few of those.

To be clear, I don't claim that its output is amazing. Only that it has
produced actionable output on many occasions. Grepping commit messages
for "Coverity" turns up several hits (many from you :) ). Most of those
are leak fixes, and I do think we have better options there. But I
recall it detecting some hard-to-find memory and logic errors, too.

> Granted, I worked around those (I thought) by using the
> `-DFLEX_ARRAY=65536` trick, but I guess that is either not working as
> designed, or it stopped working at some stage.
> 
> FWIW I have set up an Azure Pipeline to keep Git for Windows' `main`
> branch covered by Coverity:
> 
> https://dev.azure.com/git-for-windows/git/_build?definitionId=35
> 
> It essentially calls into this scripted code:
> https://github.com/git-for-windows/build-extra/blob/4676f286a1ec830a5038b32400808a353dc6c48d/please.sh#L1820-L1915

Do you have any objection to adding something like the Action I showed
eariler? It would do nothing in git-for-windows/git unless you set up
the right environment, so there shouldn't be any downside.

I admit I was not really planning to try to suppress the false positives
as you've done here; my plan was to just keep an eye on the "new"
entries (having already gone through the existing ones years ago).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux