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

[Andrew J. Schorr]

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