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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: larsi@gnus.org, daniele@grinta.net, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 3 Jul 2019 01:45:51 -0700
> 
> 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.

This dumps core because the invalid pointer is dereferenced before
fprintf is called, right?  If so, this is not relevant to the issue at
hand; just because there's a call to fprintf somewhere near the crash
locus doesn't yet mean there's a problem with that fprintf.

I said "as much as possible", and I meant that.  I don't see any
reasons to outlaw fprintf, just because some platforms buffer stderr,
or because Emacs might crash without even starting to print anything,
that'd be too unreasonable.

But I don't want us to invent a whole new family of functions just to
avoid fprintf, like your patch did.

> I know you prefer unbuffered stderr for debugging, so here's a simple 
> compromise: let's leave stderr unbuffered if ENABLE_DEBUG is defined.

Sorry, no: these messages are important in production builds as well
(those which aren't should be under some DEBUG cpp conditional
already).  Even out of people who track the master branch there seem
to be a fair amount of those who don't build with --enable-checking.

>  > 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.

What other places are those?  Let's discuss them one by one, please.