http://d.puremagic.com/issues/show_bug.cgi?id=10344
--- Comment #8 from Steven Schveighoffer <[email protected]> 2013-06-17 06:21:27 PDT --- (In reply to comment #7) > (In reply to comment #6) > > 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. But you are hijacking the return value, effectively declaring that stdout success is a critical 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'll bring it up again, maybe you missed it: Let's say there is a program that executes some database commands, then outputs how many rows affected. It returns 0 on success to modify the database, 1 on failure. The output of how many rows affected is likely less than 100 chars. So it likely would not flush before program termination. Now, consider that the author of this program has no idea about the "flush-at-end-of-main" feature (an extremely likely scenario). All his testing does not involve creating full disks, or invalid descriptors for stdout. The man page and help screen likely says that it returns 0 on successful write to the DB, non-zero on failure. It does not mention that if it fails to output "X rows affected," an error is returned. Someone using this program messes up and passes an invalid descriptor (for whatever reason). What happens is that any program using this application will see a failure, yet the database commands had succeeded. What is the utility in that? It's a completely unexpected occurrence, from both sides, and it even violates the documentation. For all intents and purposes, you have introduced a bug into every program that doesn't expect this behavior. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
