Hi Stefan, On Fri, 5 May 2017, Johannes Schindelin wrote: > On Fri, 28 Apr 2017, Johannes Schindelin wrote: > > > On Fri, 28 Apr 2017, Stefan Beller wrote: > > > > > On Thu, Apr 27, 2017 at 3:50 PM, Johannes Schindelin > > > <Johannes.Schindelin@xxxxxx> wrote: > > > > > > > I still have to find the time to figure out one more detail: how > > > > to download and extract the Coverity tool (the .zip archive has a > > > > variable name for the top-level directory), and doing that only > > > > every once in a while, say, only when there is no previously > > > > unpacked tool, or it is already 4 weeks old. > > > > > > That is an interesting problem, which I ignored as the older > > > versions of their tools still works once they release new versions. > > > So I just manually check every once in a while if they have new > > > versions out there. > > > > > > So if you find a nice solution to that problem, let me know, please. > > > > I think I have a working idea (jotting it down in the editor, > > untested): > > > > [... totally untested snippet ...] > > And now I edited it and tested it. The code is now part of the script I > use for pretty much all administrative (i.e. recurring and boring) tasks > in the Git for Windows project: > > https://github.com/git-for-windows/build-extra/commit/05b5342128 Oh, I completely forgot to mention that I tried to set the FLEX_ARRAY constant to something quite large (I used 64k), but apparently that does not work as expected, Coverity still insists on complaining about strbufs. On a second thought, it is actually quite obvious why it does not fix those reports: STRBUF_INIT has nothing to do with FLEX_ARRAY. D'oh. My next attempt to work around these bogus claims was to modify the "model file" by adding a line saying "char strbuf_slopbuf[64];", but that was sadly not picked up by Coverity either. My current thinking is that I will simply patch strbuf.c via `sed 's/^\(char struct_slopbuf\[\)1\[/&64[/'`. Ciao, Dscho