`message' not outputting the newline "atomically"

[Paul Eggert]

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

No, the caller does not dereference the bad pointer. And on some 
platforms fprintf outputs the "hello" before dumping core.

> I said "as much as possible", and I meant that.

As the above example shows, it's quite possible to output more than what 
GNU/Linux fprintf does. So, if "as much as possible" is a hard 
requirement, Emacs must stop using fprintf to format diagnostics like 
the above.

Which would be absurd and I'm not seriously proposing it. However, it is 
logically implied by the axiom that diagnostics must be unbuffered as 
much as possible. That axiom is therefore untenable as stated.

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

I agree. Similarly, there is no reason to require Emacs code to use a 
single fprintf to output each diagnostic line. Instead, we should allow 
code like this:

   fprintf (stderr, "emacs debug [");
   for (i = 0; i < 10; i++)
     fprintf (stderr, " %d", a[i]);
   fprintf (stderr, "]\n");

That is, there should not be a need to for code like this to use special 
output functions that are not used for ordinary diagnostics.

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

I agree with this as well. My patch went to that length only because it 
was the best way I saw to fix the problem under the unreasonable 
constraint that the stderr stream cannot be line-buffered. There are 
other ways to fix the problem, such as avoiding stdio and using only 
'write' for diagnostics, but these other ways are messier. As far as I 
know, nobody has suggested any patch to fix the problem other than the 
three-line patch I originally submitted, or the recent set of 
more-complicated patches.

> these messages are important in production builds as well

Of course they're important! However, the three-line change doesn't lose 
these messages in realistic scenarios involving current Emacs code. I 
proposed its ENABLE_DEBUG variant as a compromise to allay theoretical 
concerns that the three-line change might make debugging harder, not 
because conditionalizing on ENABLE_DEBUG would make a significant 
practical difference.

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

To help get that discussion started I am attaching a list of grep hits 
for some of these places in the current master source (commit 
619592df9ed4d54a63f653bf6912ecc44f46dc59). This is only a partial list. 
Although there are lots more where this came from, coming up with a 
complete list would take quite a bit more time.

fprintf-list.out
Description: Text document