Show 35 quoted lines
> Hi Stolee,
>
> On Wed, 27 Nov 2019, Derrick Stolee wrote:
>
>> 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.
>
>>>> 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.