3 ms·

If you'd check your errno when write returns -1 on standard in or standard out, SIGPIPE would not be necessary.

• userbinator 6y ago
  That would mean duplicated logic across all applications and all places in them. SIGPIPE is like an exception. If you really need to, you can catch it (to do cleanup or similar, as a sibling comment notes), but otherwise the default behaviour is fine and likely what you want. I've made use of a similar technique when reading input: in code where an EOF is a rare case, but reads occur in multiple places, you can simplify the main logic considerably if you create a function that contains the read and a longjmp() upon EOF to a specific handler which then uses state variables to decide what else needs to be done; it gets rid of all the "if EOF" duplication and puts all the special-case EOF-handling logic in one place.
  • zaarn 6y ago
    To be honest, your solution doesn't sound more maintainable, because now I have to write a complicated longjmp handler and have global state variables that interact with all my read calls. That only maybe works if you write most of the application code yourself but it would be unrealistic in larger projects that have to do more than read from stdin and pop out data on the other end. SIGPIPE should not exist, no matter what hacky ways you found to abuse it for your advantage in some edge cases.