On 11/27/2019 2:32 PM, Johannes Schindelin wrote: > 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. That's a pretty good reason to not use BUG() here!
