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

[Eli Zaretskii]

> From: Daniele Nicolodi <address@hidden>
> Date: Tue, 2 Jul 2019 22:56:05 +0200
> 
> > Then maybe you should have a look at the implementation in the various
> > libc's out there.  In all those I looked at, fwrite, fprintf,
> > etc. call fputc or its moral equivalent to emit every single character
> > they produce; they rely on the lower-level buffering layer to DTRT
> > regarding buffering.  IOW, none of the functions that write to FILE
> > stream pay any attention to the newline.  In particular, using fputc
> > for every character means that in an unbuffered stream each character
> > will be immediately written out, modulo the low-level device-specific
> > buffering in the OS.
> 
> I agree.  I would like to stress the "modulo the low-level
> device-specific buffering in the OS" part.

Console devices are usually unbuffered on that level (otherwise, you
couldn't see each character as you type them).

> Great!  Thanks!  Have you verified what is the _minimum_ length of the
> output for which you get truncated output vs no output at all?  On my
> system it is 1024 characters (and I think that this value is fairly
> standard, on the small side if anything).

I don't think the details matter for the issue at hand, because it's
unthinkable to me to rely on such details for GP diagnostic
facilities.  What's important to me is that before seeing this program
in action none of us could predict where exactly it will stop printing.

> So the only circumstance in which we would end with no output in the
> case of the line buffering, but some output with no buffering is if the
> string we are printing is longer than 1024 characters.  This does not
> change if the line contains newlines.

With this buggy program, yes.  But that's just one example, unsuitable
for making general conclusions for the issue at hand.  It just shows
that such problems are possible, and that they happen at places we
cannot easily predict in advance.

> It seems thus that if the median message printed on stderr by Emacs
> less than 1024 characters, line buffered stderr is actually allowing
> Emacs to dump more output on the terminal than unbuffered stderr :-)

You are making very general conclusions from a very specific use case,
something that can easily lead to wrong decisions.

In any case, I think this discussion exhausted itself.  If you still
disagree with the policy of leaving stderr unbuffered, let's agree to
disagree.