[Top][All Lists]

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

`message' not outputting the newline "atomically"

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

     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. And on some platforms fprintf outputs the "hello" before dumping core.

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.

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.

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

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.

I don't want us to invent a whole new family of functions just to
avoid fprintf, like your patch did.

I agree with this as well. My patch went to that length only because it was the best way I saw to fix the problem under the unreasonable constraint that the stderr stream cannot be line-buffered. There are other ways to fix the problem, such as avoiding stdio and using only 'write' for diagnostics, but these other ways are messier. As far as I know, nobody has suggested any patch to fix the problem other than the three-line patch I originally submitted, or the recent set of more-complicated patches.

these messages are important in production builds as well

Of course they're important! However, the three-line change doesn't lose these messages in realistic scenarios involving current Emacs code. I proposed its ENABLE_DEBUG variant as a compromise to allay theoretical concerns that the three-line change might make debugging harder, not because conditionalizing on ENABLE_DEBUG would make a significant practical difference.

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.

Attachment: fprintf-list.out
Description: Text document

reply via email to

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