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

[Daniele Nicolodi]

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.
However, people keeps putting me in Cc so...

On 26/06/2019 13:11, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden, address@hidden
>> From: Paul Eggert <address@hidden>
>> Date: Wed, 26 Jun 2019 11:58:26 -0700
>>
>> Emacs contains many fprintf calls like this:
>>
>>    fprintf (stderr, "Using %s\n", term);
>>
>> Here, TERM is typically a short string. On AIX and Solaris, this fprintf is 
>> implemented via three 'write' syscalls - one for "Using ", one for the 
>> contents 
>> of TERM, and one for "\n". These outputs will be broken up and hard-to-read 
>> on 
>> AIX and Solaris, if Emacs runs in parallel with other programs also 
>> generating 
>> stderr output. Using line-buffering fixes this.
> 
> 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?  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.

> Or some other similar solution?

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

Are you proposing that we selectively apply buffering in some occasions
but not others?  I am looking forward to the discussion to decide which
functions should use home-grown buffering and which ones should no...

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.

Cheers,
Dan