[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Call clearerr() on stdout before close_stream() is called.
From: |
Eric Blake |
Subject: |
Re: [PATCH] Call clearerr() on stdout before close_stream() is called. |
Date: |
Thu, 4 Feb 2016 08:16:30 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 |
On 02/04/2016 03:46 AM, David Cantrell wrote:
> This is seen in bison and possibly other programs. Bison will
> incorrectly receive SIGPIPE and terminate because close_stream() is
> picking up a rogue EPIPE in errno. Before fclose(), clearerr(stdout)
> needs to be called so that the errors it will check for are for the
> immediate call of close_stream().
> ---
> lib/closeout.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/closeout.c b/lib/closeout.c
> index 311faf4..36895a2 100644
> --- a/lib/closeout.c
> +++ b/lib/closeout.c
> @@ -106,6 +106,8 @@ close_stdout_set_ignore_EPIPE (bool ignore)
> void
> close_stdout (void)
> {
> + clearerr (stdout);
> +
This part is wrong. The whole point of close_stdout() is to detect any
error that occurred in the stream prior to closing it, not just errors
in closing the stream.
> if (close_stream (stdout) != 0
> && !(ignore_EPIPE && errno == EPIPE))
But you are correct that if close_stream() does not set errno, then we
may have a spurious EPIPE getting through to the second check. Under
what conditions would close_stream() return non-zero but not set errno?
I guess I need a bit more context to what bison is doing to why it
thinks that clearing out any earlier fwrite() and similar failures prior
to the close will prevent spurious EPIPE messages.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature