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

[Eli Zaretskii]

> Date: Sun, 9 Apr 2017 14:52:38 +0200
> From: <address@hidden>
> CC: <address@hidden>, <address@hidden>
> 
> > So if Gawk returns 0xC000014B, the programs in question will not be
> > able to interpret it in any useful way.
> 
> So you know in advance that all such programs necessarily have a finite 
> switch..case based on known EXCEPTION_* values 
> in winbase.h, and don't even have the obvious fallback:
> 
>       default: fprintf(stderr,"# Inknown exit status 0x%x\n", status);

Who do you think has been porting those programs to Windows?

And yes, there is fallback, but it is not what you think.  Showing
users a raw exit status is not a good idea, because most of them
aren't developers.  More importantly, the Windows equivalent of
WTERMSIG will fail and/or show bogus signal numbers when it sees an
unknown value.

> In any case, here's a precedent that can be found in a few clicks after 
> googling for 0xC000014B.
> As you can see, developers and/or users of that specific piece of software ( 
> a flight simulator) were able to make sense 
> of just the hexadecimal value (which was brought to their attention by a 
> generic fallback as the above), and turn this 
> knowledge into useful advice.

We are not talking about developers, we are talking about users.
Asking users to interpret hex values and look them up in headers or in
the Internet is not a sign of a user-friendly program.

> http://www.pilote-virtuel.com/img/members/81/AVSIM-CTD-Guide.pdf
> 
> HRESULT: 0xc000014B  error -- Mostly  occurs  in  networked
> computers.

HRESULT is exactly the statuses returned by device drivers.

> This is a Microsoft.net error.  The 0xc000014B is a "broken pipe"
> exception.

But Gawk is not a .NET application, so this is not relevant for us.

Look, can we agree to disagree about this and stop this endless and
useless thread?  Please?  At this point, it's a complete waste of
time.