It may be worth noting that nearly all well-written UNIX applications should set the disposition of SIGPIPE to SIG_IGN. (Preferably using sigaction, simply because that's now the preferred API, but doing it with signal is essentially equivalent in this case.)
SIGPIPE is a hack. It exists only to terminate poorly-written programs that could otherwise block a pipeline. See Bach, The Design of the UNIX Operating System; if memory serves, Bach quotes Dennis Ritchie on this point. SIGPIPE was introduced because some poorly-written programs did not check the return code from write.[1] Catching SIGPIPE in a custom handler is nearly always the Wrong Thing. The correct approach, 99.9% of the time, is to set the disposition to SIG_IGN and check the results of each system call. Personally, I think it's completely acceptable for a library to note in its documentation that the calling program MUST ignore SIGPIPE, or the library may not function properly. It's arguably OK for a library to check the disposition of SIGPIPE and if it's SIG_DFL, change it to SIG_IGN, on the grounds that the calling program is not well-written so it doesn't deserve to govern its own signal handling; but it's probably better to just fail in that case, either immediately (with a diagnostic that tells the user that the developer forgot to set the disposition of SIGPIPE) or when a SIGPIPE occurs. Libraries can't accommodate all forms of invalid behavior. You can do a certain amount of defensive coding, but at some point you're diminishing functionality for well-behaved applications in order to coddle bad ones. Don't do that. [1] There were no send, sendto, or sendmsg calls at the time. Now the argument applies equally to them. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of mahesh gs Sent: Monday, May 01, 2017 23:59 To: openssl-users@openssl.org Subject: Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write Yes, ours is a library and we do not wish to ignore the signal process wide because the consumer of our library (application) might want to handle the SIGPIPE for there own socket handling.
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
