Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH]

[arnold]

I'll work on these issues. Thanks for the feedback.

Arnold

"Andrew J. Schorr" <address@hidden> wrote:

> Hi,
>
> On Sun, Mar 19, 2017 at 01:16:01AM -0600, address@hidden wrote:
> > I'll rework the order of things. I don't know that the difference is really
> > measureable, but you're right, why go through the hassle...
>
> I see that you committed the patch. I have a few questions:
>
> - Shouldn't we update ERRNO if fflush causes an I/O error that we ignore
> because non-fatal is set? I don't think your patch does this. I based my patch
> on builtin.c:efwrite, assuming that the behavior should be consistent.
> This is an issue in builtin.c:do_fflush and in io.c:non_fatal_flush_std_file.
>
> - Also in io.c:efwrite, I fixed a bug in the fatal message where it always
> says "standard output", even if the actual problem occurred writing standard
> error:
>
> @@ -139,7 +139,7 @@ wrerror:
>               update_ERRNO_int(errno);
>       else
>               fatal(_("%s to \"%s\" failed (%s)"), from,
> -                     rp ? rp->value : _("standard output"),
> +                     rp ? rp->value : ((fp == stdout) ? _("standard output") 
> : _("standard error")),
>                       errno ? strerror(errno) : _("reason unknown"));
>  }
>  
> - In io.c:flush_io, when flushing all open files in the redirection list,
> an error return from rp->output.gawk_fflush never triggers a fatal error.
> Is that an oversight or intentional? It seems to be inconsistent with
> print/printf behavior, as implemented in builtin.c:efwrite.
>
> Regards,
> Andy