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

[Paul Eggert]

Eli Zaretskii wrote:
> I want all our diagnostic/debug messages to go outside without
> buffering as much as possible.

To do that we would have to outlaw plain fprintf too, as it buffers on GNU/Linux 
and most other platforms. For example:

   char *p = "hello";
   char *q = (char *) 1;
   fprintf (stderr, "p=%s q=%s\n", p, q);

This dumps core on GNU/Linux without producing any output. It would be possible 
to do "better" than that, by writing our own fprintf variant that does not do 
any buffering, and so outputs "p=hello q=" before it dumps core. However, this 
would be counterproductive overkill, just as it's counterproductive overkill to 
insist that stderr must not be line-buffered.

Instead, we should assume that fprintf works as advertised and that Emacs 
doesn't pass bad pointers to fprintf, and we should worry about any buffering 
issues only in the rare cases where we actually have them -- e.g., because a 
stray pointer has corrupted memory, which is something that can screw up *any* 
of these approaches.

I know you prefer unbuffered stderr for debugging, so here's a simple 
compromise: let's leave stderr unbuffered if ENABLE_DEBUG is defined. This would 
let us keep the diagnostic-interleaving fix down to three lines, while still 
having the unbuffered stderr that you prefer when you are debugging something.

> Whoa!  Is it really worth all that?  Including exposing this to Lisp?

I thought it was worth it, or I wouldn't have written the patches. 'message' is 
not the only place where Emacs issues diagnostics that can interleave, and it 
shouldn't be hard to fix the other places.