Hi Stefan,

On Fri, 5 May 2017, Johannes Schindelin wrote:

On Fri, 28 Apr 2017, Johannes Schindelin wrote:

quoted

On Fri, 28 Apr 2017, Stefan Beller wrote:

quoted

On Thu, Apr 27, 2017 at 3:50 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

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