Re: `message' not outputting the newline "atomically"

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Mon, 1 Jul 2019 09:41:52 +0200
> 
> Because you mention it explicitly, I went and checked how the
> trace-redisplay feature works.  I found only one function used by this
> feature to outputs something on stderr, debug_method_add(), and this
> function uses an fprintf() with a format string that is terminated by a
> new line:
> 
>   fprintf (stderr, "%p (%s): %s\n", ...)
> 
> to output messages to stderr.

First, you took what I wrote too literally: I said "trace-redisplay",
but didn't mean just the function by that name.  Rather, I meant all
the dump-* debug functions in that area of xdisp.c; sorry for not
being accurate enough.  Though debugging printf's without a newline at
the end are naturally relatively rare, you will find one such printf
even in this particular facility, see dump_glyph.  And if you grep our
sources for "stderr", you will see more of them: I see them in
emacs-module.c, in pdumper.c in xfaces.c, and quite a lot in
regex-emacs.c, to give just a few examples.  Yes, they are the
minority, but they are there.  And even if we go ahead and rewrite the
code to eliminate them (which I would consider a waste of energy),
they will appear again in the future, because sometimes it is just
more natural to write code that way, and avoiding that is a burden for
programmers.

More importantly, I think you are missing the main point here:

> I don't think this would be affected in any way by line buffering
> stderr.

See, this is incorrect.  The problem with line buffering is that you
see nothing at all until the newline is processed.  By contrast, an
unbuffered stream will output the text piecemeal as it is processed,
so if the program is killed half way through printing a line, you will
see more of the line with unbuffered stream than with line buffering,
even if the line ends with a newline.  How much more of that line you
will see depends on the details: the format string (if the output was
generated by the likes of fprintf), the internal implementation
details of the stdio facilities, etc.  But in general you can expect
to see more, and those additional few characters are sometimes
invaluable in debugging a problem, especially when you cannot
reproduce it at will, or not at all (imagine a bug report from another
user).

Emacs is on many platforms a multithreaded program, so it could crash
or be killed at an un-opportune moment even if the data it processes
for the current stderr printout in the main thread is itself
completely valid, let alone if Emacs is in trouble in its main thread
and some of its data is corrupted.  Thus, the situations where the
buffering _will_ affect diagnostics are real, not illusory, and the
desire to avoid losing what little diagnostics we have in these cases
has nothing to do with religion.

Once again, the people who decided to make stderr unbuffered were very
smart.  Over the years, I silently thanked them many times for that
decision, as I needed to diagnose bugs, both mine and those of others.
In high-quality software bugs are quite rare, but when they do happen,
each femto-bit of additional information is precious.  If you don't
share this basic view, if you think the need for having stderr
unbuffered needs some proof, then I guess our experiences and/or the
amounts of gray hair from insufficient diagnostics are very different.