Thread (6 messages) 6 messages, 3 authors, 2019-10-29

Re: [PATCH 1/1] vreportf(): avoid buffered write in favor of unbuffered one

From: Johannes Schindelin <hidden>
Date: 2019-10-29 14:13:50

Hi Peff,

On Tue, 29 Oct 2019, Jeff King wrote:
On Tue, Oct 29, 2019 at 01:30:51PM +0100, Johannes Schindelin wrote:
quoted
quoted
Also, this is only to help output from us that goes via vreportf() and
other codepaths in us that use stdio to write to the standard error
stream can still get mixed on Windows (I think the answer is yes,
because we wouldn't need fflush() in this patch if we are covering all
writes to the standard error stream)?
Yes, `write()` can get interrupted, so there is still a slight chance of
interleaving.

However, with `fprintf()`, apparently the MSVC runtime essentially
writes and flushes one character at a time, which will make it _much_
more likely that two competing processes write interleaved messages to
`stderr`.
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.
quoted
quoted
quoted
-	vsnprintf(msg, sizeof(msg), err, params);
+	size_t off = strlcpy(msg, prefix, sizeof(msg));
Like snprintf(3) the strlcpy() and strlcat() functions return the
total length of the string they tried to create.  For strlcpy() that
means the length of src.
True (I misread `compat/strlcpy.c` and forgot to consult the
documentation). This length can be longer than `msg`, of course.
I'd recommend xsnprintf() here. If we have a prefix longer than our
vreportf() buffer, I think a BUG() is the right outcome.
But BUG_fl() calls vreportf(). I am worried about an infinite
recursion...
quoted
I `git grep`ed and saw that only very short `prefix`es are hard-coded.
So that is a hypothetical concern.

However, Alex also indicated his discomfort with this, so I will change
the code to account for a `prefix` that is too long (the entire error
message will be clipped away in that case, which is unfortunate, but to
be expected).
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).
How about truncating already inside the prefix, then? It would miss the
entire error message... but at least it would print _something_...

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help