Re: [PATCH v3 01/10] config: initialize opts structure in repo_read_config()

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 15, 2019, 14:34 UTC
Message-ID: <nycvar.QRO.7.76.6.1904151629020.12614@tvgsbejvaqbjf.bet>
In-Reply-To: <20190412035220.GA26967@google.com>

Hi Jonathan,

On Thu, 11 Apr 2019, Jonathan Nieder wrote:

Show 5 quoted lines

> Jeff Hostetler wrote:
>
> > Initialize opts structure in repo_read_config().
>
> Good find.

Heh, it really was our CI that found it, and it was I (with valgrind's help) who identified the problem and proposed the fix. So: thank you!

> I wonder if there are some flags we can turn on with
> DEVELOPER=1 to prevent this kind of issue going undetected in the
> future (or maybe this means we need to get the valgrind or ASan
> testing modes to be fast enough for people to consistently run them).

Sadly, I do not think that either is an option. Such uninitialized memory is really hard to catch without in-depth analysis, so DEVELOPER=1 is out. And `valgrind` (or the faster alternative, DrMemory) have to spend quite a bit of time to do what they do, and it is unlikely that that could ever be made faster.

A better approach might be static analysis (and I do not mean the diet coke of static analysis that we run as part of our CI, but something as powerful as Coverity).

Sadly, Coverity makes it super hard to switch off false positives regarding e.g. our use of FLEX_ARRAY or strbuf's strbuf_slopbuf.

For quite a while, I wanted to play with [infer](https://fbinfer.com/), in the hopes that it would be possible to do customize what cannot be customized with Coverity. Alas, their use of OCaml (why do they make it so hard?) puts quite the bit of a road block ahead of me in that endeavor.

Ciao, Dscho