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

[Paul Eggert]

Eli Zaretskii wrote:
> a version with a fixed-size automatic buffer and a loop using
> it to write the message in chunks, would be a much cleaner solution
> than allocating the buffer off the heap.

Yes, that would be an improvement. I see other issues with the current master. 
It doesn't fix output-line interleaving on AIX or Solaris in places where 
GNU/Linux works OK, as AIX and Solaris fprintf functions are less buffered 
(i.e., they commonly split Emacs output into 'write' calls that are smaller than 
a line), which means that common fprintf output can be interleaved on AIX and 
Solaris when it is not interleaved on GNU/Linux. Also, the current master 
mishandles the rare case where the string has INT_MAX or more bytes, and also 
mishandles line-interleaving if the string contains newlines.

Like Lars, I'm leery about temporarily trashing the representation of a Lisp 
string in order to do I/O. There will likely be other places where we need to do 
this sort of thing, but where the data are not in Lisp strings. It's not that 
hard to efficiently output even a very long Lisp string without modifying it, so 
let's do that.

Proposed patch attached. This defaults to line buffering on glibc as well as on 
AIX and Solaris, as I've verified that glibc buffers appropriately and have used 
it pretty extensively with Emacs.

0001-Avoid-interleaving-stderr-lines.patch
Description: Text Data