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

[Eli Zaretskii]

> From: Paul Eggert <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Wed, 3 Jul 2019 16:08:36 -0700
> 
> >>      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.

Ah, you are right.  I've misread the code.

> And on some platforms fprintf outputs the "hello" before dumping
> core.

Then that's all I'd expect from such a printf.

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

I meant as much as possible by just using fprintf.

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

Yes, which is why I was certain what I wrote will not be interpreted
in this way.

> > 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");

Sure.

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

Right.

However, using the above for diagnostic output, or for informative
messages output during an Emacs build, is unrelated to the original
problem raised by Lars.  That problem was with messages from a running
Emacs, outside of the build process (because the build process use
case can be handled by the Make's -O switch), i.e. when Emacs is run
as part of some script.

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

Thanks.  I reviewed the list, and I think only message3_nolog and
vmessage need to be changed.  All the rest are fatal error messages
and debugging diagnostics of sorts, and quite a few of them even
conditioned by some CPP symbol that is only defined in debugging
builds.

One way of fixing message3_nolog and vmessage would be to use in them
that additional line-buffer stream you defined in your patch.