4 ms·

> There's a reason that Unix sends EPIPE to a process when writing to a broken pipe, and why the default handler for SIGPIPE is to terminate the process. As an

> There's a reason that Unix sends EPIPE to a process when writing to a broken pipe, and why the default handler for SIGPIPE is to terminate the process. As an author and consumer of cross platform software I can't rely on that - no SIGPIPE on windows - not to mention it's a pretty coarse hammer. Return value + errno is the way to go if I actually care about the exact behavior. One can wrap the call and panic/abort/terminate, but most people don't bother to do that, nor can I particularly blame them for not bothering (especially when I generally don't either.) > I don't think I've ever seen C code that fails to check fork for an error condition, though I'm usually only ever reading my code and the code of widely used open source projects. I'd be curious if git blame shows they had that error handling from day 1, or if it was generally added in response to heisenbugs. My money is on the latter, but perhaps you're generally exposed to better codebases than I am.

wahern 7y ago
> As an author and consumer of cross platform software I can't rely on that - no SIGPIPE on windows - not to mention it's a pretty coarse hammer. But shell programming and process pipelines aren't common on Windows. Rust shouldn't have changed the default behavior. SIGPIPE serves a critical role on Unix by ensuring that processes don't keep running when their consumers disappear. > Return value + errno is the way to go if I actually care about the exact behavior. One can wrap the call and panic/abort/terminate, but most people don't bother to do that, nor can I particularly blame them for not bothering (especially when I generally don't either.) Fortunately in Rust you're usually forced to handle the failure condition. The problem is with FFI to existing libraries that implicitly rely on default Unix semantics. > I'd be curious if git blame shows they had that error handling from day 1, or if it was generally added in response to heisenbugs. My money is on the latter, but perhaps you're generally exposed to better codebases than I am. Admittedly, I don't hang in the "I copied this code from Stack Exchange" or "IDE code completion is essential" crowds. When programming in C I always have the POSIX and C standards handy, even though I've memorized much of it already. I try to do the same for other languages, to the extent it's possible. Someone else linked to an earlier comment of theirs where they complained that the POSIX spec for fork was only the 8th hit on Google. Perhaps their problem was having a habit of Googling the usage for a core Unix API rather than using the freely available and eminently readable specs, which can be kept locally. I have well over USD $1000 of ISO specifications on my hard drive, and as far as specifications go the POSIX and C specifications stand out for their concision and clarity. This is true even when pitting them against the documentation for languages like Perl, Python, Go, or Rust.
- MaulingMonkey 7y ago
  > Rust shouldn't have changed the default behavior Agreed, didn't mean to imply otherwise. > ... Agreed > Perhaps their problem was having a habit of Googling the usage for a core Unix API rather than using the freely available and eminently readable specs, which can be kept locally. To the degree that it is their problem, it's an understandable one. Not everyone has $1k to drop on text documents, and those standards may not cover the bulk - or even a particularly significant fraction - of the APIs one is dealing with on a day to day basis, making their value as an investment rather limited. And two decades ago, I was gobsmacked to learn that C++ had a standard library at all, with it's own string type - std::string - that I could use where Borland's AnsiString was unavailable. Things have admittedly improved slightly since then, but you can't buy a spec without knowing it even exists! And I'll admit I frequently google instead of refering to the standards I have bought. They're useful for resolving language lawyer disputes (although the occasional defect report limits even the standard's usefulness for that), but I won't call them particularly amazing references. Their main advantage is in being authoratative. Of course, implementations may not always perfectly match the standard they're supposed to match as well... when I care about the details, I'm more likely to dive into the implementation's source code rather than the spec.

wahern 7y ago

> As an author and consumer of cross platform software I can't rely on that - no SIGPIPE on windows - not to mention it's a pretty coarse hammer. But shell programming and process pipelines aren't common on Windows. Rust shouldn't have changed the default behavior. SIGPIPE serves a critical role on Unix by ensuring that processes don't keep running when their consumers disappear. > Return value + errno is the way to go if I actually care about the exact behavior. One can wrap the call and panic/abort/terminate, but most people don't bother to do that, nor can I particularly blame them for not bothering (especially when I generally don't either.) Fortunately in Rust you're usually forced to handle the failure condition. The problem is with FFI to existing libraries that implicitly rely on default Unix semantics. > I'd be curious if git blame shows they had that error handling from day 1, or if it was generally added in response to heisenbugs. My money is on the latter, but perhaps you're generally exposed to better codebases than I am. Admittedly, I don't hang in the "I copied this code from Stack Exchange" or "IDE code completion is essential" crowds. When programming in C I always have the POSIX and C standards handy, even though I've memorized much of it already. I try to do the same for other languages, to the extent it's possible. Someone else linked to an earlier comment of theirs where they complained that the POSIX spec for fork was only the 8th hit on Google. Perhaps their problem was having a habit of Googling the usage for a core Unix API rather than using the freely available and eminently readable specs, which can be kept locally. I have well over USD $1000 of ISO specifications on my hard drive, and as far as specifications go the POSIX and C specifications stand out for their concision and clarity. This is true even when pitting them against the documentation for languages like Perl, Python, Go, or Rust.

MaulingMonkey 7y ago
> Rust shouldn't have changed the default behavior Agreed, didn't mean to imply otherwise. > ... Agreed > Perhaps their problem was having a habit of Googling the usage for a core Unix API rather than using the freely available and eminently readable specs, which can be kept locally. To the degree that it is their problem, it's an understandable one. Not everyone has $1k to drop on text documents, and those standards may not cover the bulk - or even a particularly significant fraction - of the APIs one is dealing with on a day to day basis, making their value as an investment rather limited. And two decades ago, I was gobsmacked to learn that C++ had a standard library at all, with it's own string type - std::string - that I could use where Borland's AnsiString was unavailable. Things have admittedly improved slightly since then, but you can't buy a spec without knowing it even exists! And I'll admit I frequently google instead of refering to the standards I have bought. They're useful for resolving language lawyer disputes (although the occasional defect report limits even the standard's usefulness for that), but I won't call them particularly amazing references. Their main advantage is in being authoratative. Of course, implementations may not always perfectly match the standard they're supposed to match as well... when I care about the details, I'm more likely to dive into the implementation's source code rather than the spec.