[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniele Nicolodi
Subject: Re: `message' not outputting the newline "atomically"
Date: Sun, 30 Jun 2019 22:11:48 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

On 26/06/2019 20:34, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Daniele Nicolodi <address@hidden>
>> 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.

What I meant is that you have a strong believe that there may be cases
in which there is non zero probability that Emacs segfaults after
writing a string a sequence of characters to stderr that does not end in
a newline but at the same time contains crucial (or at least valuable)
information that will help diagnose the problem.  I call this a
religious believe because (as far as I can tell) no example of such
occurrence has been provided and (in an unbounded system) logically
proving the non-existence of something is impossible (as the existence
of God in the universe, thus me calling this a religious believe).  Of
course the Emacs' codebase is bounded, however an exhaustive list of the
supported platforms does not exist, making the possibilities practically
unbounded.  I thus think it is on you to provide a plausible eou xample.

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

Just add an fflush() after the write()s you care about...

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

I suggest an fflush() after every message that does not terminate in a
newline and that must absolutely end in the terminal if Emacs crashes,
if any exists (see above).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]