bug-gawk
[Top][All Lists]
Advanced

[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 20:03:00 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0

On 08/04/2017 19:51, Eli Zaretskii wrote:
 Date: Sat, 8 Apr 2017 19:19:43 +0200
 From:<address@hidden>
 CC:<address@hidden>,<address@hidden>

 You wrote:

   +/* 0xC0000008 is EXCEPTION_INVALID_HANDLE, somewhat appropriate for EPIPE */

 but "invalid handle" does not give a meaningful clue to the startled developer.

It's an exception value that is the closest in meaning to what happens
here.

The model I used is that of a program that crashes due to the Windows
equivalent of SIGSEGV.  Such a program exits with a status of
0xC0000005, which is the value of EXCEPTION_ACCESS_VIOLATION.  So I
looked for an exception that would be related to broken pipe, and this
is the closest one I found.

 A better value would somehow point to what has actually happened, like 
ERROR_BROKEN_PIPE:

No, ERROR_BROKEN_PIPE is an error code, not an exception code.

 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

I don't see how exiting with arbitrary status values could serve any
useful purpose in this case.  Some ported programs (like Guile, for
example) need to see the 0xC000000n codes of the programs they invoke
to produce reasonable diagnostics, and the exit status I've chosen
plays well with those programs.

As I said, you're the Windows expert, but I still fail to see what reasoning can bring the developer, upon discovering that "invalid handle" exit status, to the proper thinking that it is a valid handle to a pipe, with the other side closed.

That said, I've seen so many Windows programs report "Unknown Error" that I guess this lack of rigor in error reporting is part of the culture. I won't sweat for Windows.

_________________________________________________________________________________________________________________________

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.




reply via email to

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