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

[Daniele Nicolodi]

On 01/07/2019 08:39, Eli Zaretskii wrote:
> 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).

I think you didn't understand my point, and your selective quoting makes
me thing you are trying to warp what i wrote in your favor. I was
arguing that in the case of a fprintf() with a format string that ends
in a new line there is no way to obtain a partial output, with stderr
unbuffered or line buffered. On any sane implementation of the c library
Either you will get it all or nothing. If you don't think this is the
case I would like to know in what circumstances this does not hold true
and how those apply to Emacs.

Cheers,
Dan