[Issue 10344] Exiting _Dmain should flush all FILE*s and return nonzero on failure

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Jun 14 15:48:43 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=10344



--- Comment #6 from Steven Schveighoffer <schveiguy at yahoo.com> 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: -------


More information about the Digitalmars-d-bugs mailing list