Re: [PATCH 1/1] vreportf(): avoid buffered write in favor of unbuffered one
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 29, 2019, 16:44 UTC
- Message-ID
- <xmqqtv7r5wn3.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20191029134932.GA2843@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> Wow, they have truly taken "unbuffered" to a whole new level. > > I don't mind seeing this for all platforms, though. I can't think of any > downside, and having one less moving part to contend with in our > error-reporting code seems like a good thing.
FWIW, it was my mistake to sound as if I was unhappy to see this done on all platforms. As long as the end result is to reasonably buffer, I do not mind us (as opposed to the system library we sometimes cannot trust) being the one who implements the buffering.
I very much prefer to see the same code run everywhere than #ifdef in this case.
Show 6 quoted lines
> I'd recommend xsnprintf() here. If we have a prefix longer than our > vreportf() buffer, I think a BUG() is the right outcome. > ... > I'd disagree here. Any caller sending an arbitrarily-large prefix is > holding it wrong, and we'd probably want to know as soon as possible > (and a BUG() is our best bet there).
Yes. We are not using an unvetted input as the prefix here, if somebody needs to use a larger prefix somewhere, that patch needs to argue the pros-and-cons between making the buffer larger or shortening that larger prefix.