http://d.puremagic.com/issues/show_bug.cgi?id=10344
--- Comment #6 from Steven Schveighoffer <[email protected]> 2013-06-14 15:48:41 PDT --- (In reply to comment #5) > So, it will only hijack the return code if the return code was 0. What is OK about overriding the return code of 0, but not an error return code? If stdout output is not critical, or even viewed, then there is no significant error. Hijacking 0 when the program actually succeeded is not preferred. I will say that *relying* on this behavior is a programming error -- it means the program is relying on an implementation detail (buffer size) to NOT throw an exception during normal execution. So from that point of view, it kind of makes sense that one would want to see an error rather than not. But the proposed solution doesn't seem to be any better. It may end up simply breaking something that was working fine (for that particular usage) before the change, for no good reason. In fact, any change we make can be viewed this way (throwing on first write, for instance). I'm actually feeling more like we just should do nothing, because the use case is mostly invalid (starting out with an invalid file descriptor), and the error will be more annoying than useful. The corner cases are so rare and vague that I don't see this helping anyone. It should be noted that this whole discussion came about because a developer naively assumed that the code posted in the description was attempting to write to the file descriptor, ignoring the failure, and continuing. When actuality, the test is wrong. They just didn't understand that C intelligently decides not to flush after newlines when the output is not a console. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
