Jim, > Imagine a scenario in which the pipe reader is expected always to > be reading, and so the pipe writer can expect that any write failure with > errno==EPIPE indicates the reader has terminated unexpectedly.
If the writer should terminate first, the reader can still detect the failure using SIGPIPE and/or SIGCHLD. Since you say that you consider ignoring the signal to be discouraged, these programs should not see EPIPE anyway. Yes, you also said: > Some environments (mis-configured login/csh) have > resulted in the default SIGPIPE handler being SIG_IGN. ... but there are so many other problems that could result from misconfiguration, such as fd 0/1/2 not being open. I don't think programs that do not impact security should try to cater for this; programs that do care about security, instead, are already armored against misconfigured signals and everything else. Furthermore, it's not gnulib's purpose to do this currently, and even if there was a "super-security" module, it would not make Bruno's proposal any less viable. Replying to Bruno, > If you want both scenarios - the "don't know which of the two terminates > first" > and the "writer must terminate first" - to be supported by close_stream and > close_stdout, IMO the program needs to be able to tell these functions about > it, probably through a global variable 'bool ignore_epipe' or similar. I think this is not necessary. Most of the time, programs have no need to distinguish *which* pipe was in error, so they are okay with SIGPIPE or SIGCHLD. The global would be needed for programs that deal with multiple pipes, cannot rely on SIGCHLD (including the case when they want to be 100% correct and don't want to muddle with async-signal-safety), *and* need to error out if the reader terminates first. Paolo
