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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Wed, 26 Jun 2019 13:36:54 -0600
> 
> Not that I care much about this, I feel that defending the use case of
> debugging Emacs through printf() statements is rooted in believes akin
> to religious ones, and religious arguments cannot be won with logic.

It isn't religious at all.  We have built-in debugging capabilities
that use stderr, see the trace-redisplay feature as one example.  This
particular feature is very valuable for me, as it happens.

> > Can't we also fix that by replacing the above with 'sprintf' followed
> > by 'write'?
> 
> Why is re-implementing line buffering in Emacs any better than using
> libc line buffering?

Because we can apply that on a per-case basis, whereas setvbuf is
global and irreversible.

> For your main argument in the thread, we would be loosing crucial
> debug information if something goes irreparably wrong between the
> string preparation and the write().  And given how error-prone is
> string manipulation in C, there are much higher chances that this
> will happen if we start doing that for every function that want to
> print something on stderr.

My main argument is actually that the issue this thread is trying to
fix is minor, even insignificant.  But given that some people pressure
to find a solution, I propose various compromises.  As any compromise,
they are somewhat ugly.  My personal preference would be to leave
things as they are.

> Any solution requires buffering of the output till the first newline.
> And you are opposed to buffering.

I'm opposed to buffering stderr globally, yes.  But I can agree to
that in specific cases.  The problem is, setvbuf doesn't allow
selective buffering.

> Are you proposing that we selectively apply buffering in some occasions
> but not others?

YES!

> However, if that is the route you are suggesting, it is much easier to
> enable line buffering unconditionally ad place fflush() calls where it
> matters, than the other way around.

You are suggesting fflush after every character written?  That's
impractical, and we usually use something other than fputc to output
the messages.