[Top][All Lists]

[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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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