[Toybox] default SIGPIPE handler that calls _exit(0)?

[Rich Felker]

On Mon, Apr 27, 2015 at 08:36:53AM -0700, enh wrote:
> On Sun, Apr 26, 2015 at 7:30 PM, Rich Felker <dalias at libc.org> wrote:
> > On Sat, Apr 25, 2015 at 12:14:44PM -0700, enh wrote:
> >> what's the plan wrt SIGPIPE? the desktop is pretty inconsistent. many
> >> (but not all) commands install a signal handler that does _exit(0).
> >> others (coreutils 8.21's ls, say) do nothing. normally "what you do
> >> about SIGPIPE" isn't a problem but on Android that leads to a crash
> >> report and people filing "ls crashed" bugs against me. (our default
> >> shell PS setup is also noisy about crashes.)
> >
> > Why not just *block* SIGPIPE (with sigprocmask) so that the write
> > returns an error (EPIPE) and the program applies the same logic it
> > would for any other write error?
> 
> toybox does a little better than toolbox there thanks to xwrite, but
> i've yet never met anyone who checks the return value of printf...
> 
> plus there's the question of whether giving up because you're writing
> to a broken pipe is an error exit or not. you could add a special case
> to xwrite (and add xprintf and xputs and...), but since the whole idea
> is that code shouldn't have to care, it's easier just to install a
> signal handler that does _exit(0).

_exit(0) is wrong and broken. It reports success when the command did
not succeed. Failure of the caller to recognize that it didn't succeed
can result in data loss. If anything the right behavior for the signal
handler would be _exit(1) not _exit(0). But I think xwrite/xprintf
solves the issue more elegantly. Note that even if you don't check
every printf, you still get the error status from ferror and/or fflush
at close time (if you check them) but that might result in a lot of
wasted cpu time if you continue processing/writing after a pipe broke.

Rich

 1430151103.0