[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH]
From: |
alexandre.ferrieux |
Subject: |
Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH] |
Date: |
Sat, 8 Apr 2017 19:19:43 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 |
On 08/04/2017 13:38, Eli Zaretskii wrote:
From: address@hidden
Date: Wed, 29 Mar 2017 10:26:28 -0600
Cc: address@hidden, address@hidden
Eli Zaretskii<address@hidden> wrote:
> As to whether this result is horrible: I guess it depends on whether
> we want the behavior to be more consistent across platforms. I'd like
> at least to "fix" errno in this case to be EPIPE, then we can talk
> about what exit status to produce. Does that make sense?
Sounds like a plan to me. Thanks!
Now done on the master branch, including the proper exit status.
You wrote:
+/* 0xC0000008 is EXCEPTION_INVALID_HANDLE, somewhat appropriate for EPIPE */
but "invalid handle" does not give a meaningful clue to the startled developer.
A better value would somehow point to what has actually happened, like
ERROR_BROKEN_PIPE:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365747(v=vs.85).aspx
"
If an anonymous pipe is being used and the read handle has been closed,
when WriteFile attempts to write using the pipe's corresponding write
handle, the function returns FALSE and GetLastError returns ERROR_BROKEN_PIPE.
"
Of course that's a small number (error) not in the 0xC... range like your exception; by analogy with unix I'd just add
an unused, large constant like 0xE0000000, but you're the Windows expert.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], Eli Zaretskii, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH],
alexandre.ferrieux <=
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], Eli Zaretskii, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], alexandre.ferrieux, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], Eli Zaretskii, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], alexandre.ferrieux, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], Eli Zaretskii, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], alexandre.ferrieux, 2017/04/08
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], Eli Zaretskii, 2017/04/09
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], arnold, 2017/04/09
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], alexandre.ferrieux, 2017/04/09
- Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH], Eli Zaretskii, 2017/04/09