[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: `message' not outputting the newline "atomically"
Date: Wed, 3 Jul 2019 01:45:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

Eli Zaretskii wrote:
I want all our diagnostic/debug messages to go outside without
buffering as much as possible.

To do that we would have to outlaw plain fprintf too, as it buffers on GNU/Linux and most other platforms. For example:

   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. It would be possible to do "better" than that, by writing our own fprintf variant that does not do any buffering, and so outputs "p=hello q=" before it dumps core. However, this would be counterproductive overkill, just as it's counterproductive overkill to insist that stderr must not be line-buffered.

Instead, we should assume that fprintf works as advertised and that Emacs doesn't pass bad pointers to fprintf, and we should worry about any buffering issues only in the rare cases where we actually have them -- e.g., because a stray pointer has corrupted memory, which is something that can screw up *any* of these approaches.

I know you prefer unbuffered stderr for debugging, so here's a simple compromise: let's leave stderr unbuffered if ENABLE_DEBUG is defined. This would let us keep the diagnostic-interleaving fix down to three lines, while still having the unbuffered stderr that you prefer when you are debugging something.

> Whoa!  Is it really worth all that?  Including exposing this to Lisp?

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.

reply via email to

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