Re: Git Test Coverage Report (Nov 25)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 27, 2019, 19:32 UTC
Message-ID: <nycvar.QRO.7.76.6.1911272029050.31080@tvgsbejvaqbjf.bet>
In-Reply-To: <59ae5223-6dd8-00cd-4c39-b307f8364457@gmail.com>

Hi Stolee,

On Wed, 27 Nov 2019, Derrick Stolee wrote:

Show 10 quoted lines

> On 11/26/2019 3:46 PM, Johannes Schindelin wrote:
>
> > [...] the Windows build.
>
> Sorry that I have not set up a Windows build, but the Linux test-coverage
> build already takes a long time so adding Windows would be complicated.
> (Not to mention that merging the uncovered lines across two platforms would
> be a huge challenge.)
>
> If anyone wants to consider such an effort, I'm willing to play along.

I fear it is even worse: once upon a time, I tried to set up a gcov run with mingw-w64-gcc, and it failed miserably (there was simply no output at all).

So I, for one, am completely comfortable with keeping the status quo for the time being.

Show 9 quoted lines

> >> Johannes Schindelin	116d1fa6 vreportf(): avoid relying on stdio buffering
> >> usage.c
> >> 116d1fa6 16) fprintf(stderr, "BUG!!! too long a prefix '%s'\n", prefix);
> >> 116d1fa6 17) abort();
> >> 116d1fa6 22) *p = '\0'; /* vsnprintf() failed, clip at prefix */
> >
> > Those are defensive programming, so this is expected not to be covered.
>
> I wonder why we are not using BUG() here (for the fprintf and abort).

It's because `BUG()` calls `vreportf()`, and even if the _current_ version would bail out at some point, I would be uncomfortable calling `BUG()` from `vreportf()` and risk a (future-only) recursion ad infinitum.

Thanks! Dscho