http://d.puremagic.com/issues/show_bug.cgi?id=10344
--- Comment #7 from Andrei Alexandrescu <[email protected]> 2013-06-14 18:45:20 PDT --- (In reply to comment #6) > (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 the program was to return an error code, it meant it has failed for whatever reason. The fact that among other failures it also failed to flush is of no consequence. > If stdout output is not critical, or even viewed, then there is no > significant > error. We're not to decide what is critical to the program and what's not. We are to report an unexpected error. > Hijacking 0 when the program actually succeeded is not preferred. By whom? Why? What's the purpose of saying this? This is just a statement without any justification. > 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. I think you are wrong in several obvious ways, plus a few subtler ones. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
