www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10344] New: Exiting _Dmain should flush all FILE*s and return nonzero on failure

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344

           Summary: Exiting _Dmain should flush all FILE*s and return
                    nonzero on failure
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrei erdani.com



PDT ---
Consider:

// file test.d
import std.stdio;
void main()
{
    writeln("test");
}

This program may be run with a file that is not writable like this:

./test 1</dev/null

Although writeln() is checked, the program appears to succeed (returning 0 to
the OS) because of buffering: (a) /dev/null is not line-buffered, and (b)
flushing files upon exiting the program is unchecked.

To wit, this will indeed work correctly in all scenarios:

// file test.d
import std.stdio;
int main()
{
    writeln("test");
    return fflush(null) != 0;
}

We should add the call to fflush to main() and return nonzero IF AND ONLY IF:
(a) fflush(null) fails, and (b) the program would have otherwise returned 0.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 12 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com



12:09:06 PDT ---
On one hand, I disagree that stdout failing to flush on program exit should
trump whatever main returns.  The application simply may not care.

On the other hand, if stdout is invalid, and any output is done, writeln could
fail itself at any time.  If this is not expected, the effect is the same.

This can be opt-out also:

int main()
{
   ....
   try { fflush(NULL); } catch {}
   return 0;
}

So I'm OK with this.

I still think it's worth checking on first write whether the file descriptor is
valid (this only needs to be done for File instances opened with an existing
FILE * or file descriptor).  The advantage here is that the error occurs at
first use, not at some time later (possibly at program end!).  If the user is
simply using an invalid file descriptor, I'd rather see the exception at use,
not on program exit.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




PDT ---


 On one hand, I disagree that stdout failing to flush on program exit should
 trump whatever main returns.  The application simply may not care.


I just tested this:

import std.stdio;
int main()
{
    return fflush(null);
}

Fortunately it never fails, which is quite awesome because it means it'll fail
only if the application attempted to produce output but was unable to.

If the upstream app has no interest in whether the invoked app produced proper
output, they can ignore the exit code.


 On the other hand, if stdout is invalid, and any output is done, writeln could
 fail itself at any time.  If this is not expected, the effect is the same.
 
 This can be opt-out also:
 
 int main()
 {
    ....
    try { fflush(NULL); } catch {}
    return 0;
 }
 
 So I'm OK with this.


fflush doesn't throw.


 I still think it's worth checking on first write whether the file descriptor is
 valid (this only needs to be done for File instances opened with an existing
 FILE * or file descriptor).  The advantage here is that the error occurs at
 first use, not at some time later (possibly at program end!).  If the user is
 simply using an invalid file descriptor, I'd rather see the exception at use,
 not on program exit.


That's nice, but I'm not sure whether we should do it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




07:25:43 PDT ---




 On one hand, I disagree that stdout failing to flush on program exit should
 trump whatever main returns.  The application simply may not care.


 
 I just tested this:
 
 import std.stdio;
 int main()
 {
     return fflush(null);
 }
 
 Fortunately it never fails, which is quite awesome because it means it'll fail
 only if the application attempted to produce output but was unable to.


Right, this is definitely ideal.  One should not throw an error because stdout
is broken if you never use stdout.

But that was not my point.  My point is that what you write in stdout may not
be critical.  It may be a side effect, like let's say a log or informational
message.  In that case, you don't care if it fails, you are more interested in
what the program decides the error code should be.

For instance, imagine a program that takes as input some database commands, and
prints out how many rows were updated, but returns 1 if the database commands
failed, and 0 if it succeeded.  I don't care as an upstream script function
whether "5 rows updated" successfully printed, I only care if the database was
successfully updated.


 This can be opt-out also:
 
 int main()
 {
    ....
    try { fflush(NULL); } catch {}
    return 0;
 }
 
 So I'm OK with this.


 
 fflush doesn't throw.


oops, I meant stdout.flush(); stderr.flush();


 I still think it's worth checking on first write whether the file descriptor is
 valid (this only needs to be done for File instances opened with an existing
 FILE * or file descriptor).  The advantage here is that the error occurs at
 first use, not at some time later (possibly at program end!).  If the user is
 simply using an invalid file descriptor, I'd rather see the exception at use,
 not on program exit.


 
 That's nice, but I'm not sure whether we should do it.


It's simply an optimization.  There is little overhead required (a simple bool
indicating whether it should check the fd on first write).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 13 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Koroskin Denis <2korden gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |2korden gmail.com



---
Will that affect int main() { .. } functions as well?

Consider the following example:

int main()
{
   Result result = doLogic(); // does some logic, uses writeln() to indicate
progress
   return mapResultToReturnCode(result);
}

Let's say it's a video encoding program, and is a part of a longer toolchain
(some other program will do something else based on return code).

Will writeln()/flush() hijack main return code even though the programmer
EXPLICITLY returned something else?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Peter Alexander <peter.alexander.au gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.alexander.au gmail.co
                   |                            |m



14:47:41 PDT ---


 Will writeln()/flush() hijack main return code even though the programmer
 EXPLICITLY returned something else?


At the end of the original post, Andrei wrote:

"We should add the call to fflush to main() and return nonzero IF AND ONLY IF:
(a) fflush(null) fails, and (b) the program would have otherwise returned 0."

So, it will only hijack the return code if the return code was 0.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




15:48:41 PDT ---



 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: -------
Jun 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




PDT ---



 

 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: -------
Jun 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




06:21:27 PDT ---




  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: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




PDT ---


 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.


But this is an argument against our current approach to stdout (we check and
throw on all errors). The error in the program you mentioned may very well
intervene in writeln under one or more of the following conditions:

* sufficient characters output
* line buffered or unbuffered stdout

In such cases, succeeding to produce stdout is just as unimportant to the
program, but the program will fail with nonzero error code. Are you saying we
should change that?

At the highest level, it is well understood there examples can be given that
show the stdout output was of small consequence to the program. The point is we
cannot decide on behalf of the program that it's okay to have truncated output.

In D all flushes of stdout are checked and exceptions are thrown if they fail.
The last flush is not special in any way and must behave the same.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




08:28:30 PDT ---


 
 But this is an argument against our current approach to stdout (we check and
 throw on all errors).


Yes, but there is a difference -- the error occurs DURING program execution.

In fact, one could diligently check for exceptions (and throw them away because
output isn't critical) on every writeln, but still have this unexpected error.


 The error in the program you mentioned may very well
 intervene in writeln under one or more of the following conditions:
 
 * sufficient characters output


My post specifically said this is not the case.  a simple output message like
"X rows updated" will never exceed 4096 characters.


 * line buffered or unbuffered stdout


The conditions that cause this error preclude having stdout decide to flush on
newlines (a console is neither an invalid descriptor, nor in danger of running
out of space).


 In such cases, succeeding to produce stdout is just as unimportant to the
 program, but the program will fail with nonzero error code. Are you saying we
 should change that?


No, the program has not decided what it will return at that point.  It's a
standard exception, and if unhandled, that is a bug, or expected case in the
program (that should be documented).  I agree it's unlikely for most developers
to handle failed stdout, but it's reasonable that a diligent and careful
programmer will wrap his entire program in a try-catch block, and expect all
exceptions to be handled by that block.


 At the highest level, it is well understood there examples can be given that
 show the stdout output was of small consequence to the program. The point is we
 cannot decide on behalf of the program that it's okay to have truncated output.


I don't think we can decide either way.  At the time this flush occurs, the
program has made a concrete decision of success or failure.  Overriding that
decision is not something the runtime should be doing.

Consider the case where the filesystem driver fails to finish writing the file
after the program exits.  How do we handle that?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




12:28:21 PDT ---


 I don't think we can decide either way.  At the time this flush occurs, the
 program has made a concrete decision of success or failure.  Overriding that
 decision is not something the runtime should be doing.


The program has made a decision that assumes writes to stdout, if any, have
succeeded.


 Consider the case where the filesystem driver fails to finish writing the file
 after the program exits.  How do we handle that?


That is not under our control.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




13:21:02 PDT ---


 The program has made a decision that assumes writes to stdout, if any, have
 succeeded.


You seem to be ignoring the use case.  The return code is based on database
update success, not stdout success.  In fact, I can write the code in such a
way that specifically ignores stdout failures, yet still have this come up.


 Consider the case where the filesystem driver fails to finish writing the file
 after the program exits.  How do we handle that?


 
 That is not under our control.


None of this is under our control.  It's outside our visibility.  But the
effect is the same -- data is not written.  We can't say definitively that a D
program guarantees the data goes to it's final destination.  The error is in
fact useless because success doesn't guarantee the write occurs.

In fact, all a success guarantees is that the program succeeded according to
it's charter.

I have another compromise that I will post to this bug report separately.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




13:25:14 PDT ---
Proposed compromise:

In addition to the proposed change that throws on the final flush and adjusts
the error code, provide a writable flag in File that indicates an i/o error
should not throw.  Then if stdout output errors are deemed not critical, the
final flush will not throw or adjust the error code.  In addition, any failure
during execution when fflush is called will not throw.

This might actually be a better solution to the use case I have provided,
because the intent is clearly stated from the developer up front, that stdout's
failures are not critical to the program.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




13:31:35 PDT ---




 The program has made a decision that assumes writes to stdout, if any, have
 succeeded.


 
 You seem to be ignoring the use case.


Apparently you are ignoring my reply to it, which addressed it directly
acknowledging that the success of producing stdout output does not define the
success of the program.


  The return code is based on database
 update success, not stdout success.


I understood that the first time.


 In fact, I can write the code in such a
 way that specifically ignores stdout failures, yet still have this come up.


No, if you flush (and catch) at the end of the program you're in good shape.
Consider:

import std.stdio;
int main()
{
    writeln("test");
    fflush(null);
    return fflush(null);
}

This will never fail. The first flush fails, but the second does not.


 Consider the case where the filesystem driver fails to finish writing the file
 after the program exits.  How do we handle that?


 
 That is not under our control.


 
 None of this is under our control.  It's outside our visibility.  But the
 effect is the same -- data is not written.  We can't say definitively that a D
 program guarantees the data goes to it's final destination.  The error is in
 fact useless because success doesn't guarantee the write occurs.


Untrue. The success guarantees that the program succeeded in passing data
forward to the operating system. Please let's not make this an argument about
the tree in the forest.

D checks all flushes. Consequently it should check the last flush. No two ways
about it. End of story.


 In fact, all a success guarantees is that the program succeeded according to
 it's charter.


That is correct. The problem with ignoring the last flush is that we assume
that the charter of the program is it's okay to produce truncated output.


 I have another compromise that I will post to this bug report separately.


Looking forward to it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




13:34:56 PDT ---


 Proposed compromise:
 
 In addition to the proposed change that throws on the final flush and adjusts
 the error code, provide a writable flag in File that indicates an i/o error
 should not throw.  Then if stdout output errors are deemed not critical, the
 final flush will not throw or adjust the error code.  In addition, any failure
 during execution when fflush is called will not throw.
 
 This might actually be a better solution to the use case I have provided,
 because the intent is clearly stated from the developer up front, that stdout's
 failures are not critical to the program.


Sounds good, but this is the approach taken by C++'s iostreams:
http://msdn.microsoft.com/en-us/library/xybta3wf(v=vs.80).aspx. It hasn't
enjoyed a lot of success.

Then we'll need to define ways for people to access error codes etc. which
means writeln and friends would need to return them, or provide lastError()
APIs etc. It would necessitate some design.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




13:58:51 PDT ---


 Then we'll need to define ways for people to access error codes etc. which
 means writeln and friends would need to return them, or provide lastError()
 APIs etc. It would necessitate some design.


We don't need to design any APIs.  Just don't throw.  If you want to handle
errors as they happen, don't set the flag.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Lionello Lunesu <lio+bugzilla lunesu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lio+bugzilla lunesu.com



23:32:08 PDT ---
Adding

    if (fflush(null) != 0)
            throw new Error("write error");

in druntime/src/rt/dmain2.d line 621, between rt_moduleDtor() and gc_term(),
seems to work:

$ ./helloworld 1</dev/null
object.Error: write error
----------------
5   hw                                  0x0000000108047755 extern (C) int
rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void
tryExec(scope void delegate()) + 45
6   hw                                  0x0000000108047709 _d_run_main + 457
7   hw                                  0x0000000108047538 main + 20
8   libdyld.dylib                       0x00007fff8e6107e1 start + 0
9   ???                                 0x0000000000000001 0x0 + 1
----------------

But the question is: what to throw? 

Unfortunately ErrnoException is in phobos, not in druntime. We could move it to
druntime (adding an alias for backcompat.) Moving it would not introduce any
additional dependencies to druntime.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



01:51:27 PDT ---


 But the question is: what to throw? 


I think throwing an Error would be fine, because the user isn't going to be
catching it anyway.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




02:32:54 PDT ---




 But the question is: what to throw? 


 
 I think throwing an Error would be fine, because the user isn't going to be
 catching it anyway.


It would be nice to show at least the actual error, based on errno, instead of
an hardcoded string.

druntime does have the declaration for the C runtime strerror() and .errno so
we can do:

        if (fflush(null) != 0)
        {
            auto s = strerror(.errno);
            throw new Error(s[0..strlen(s)].idup);
        }

resulting in:

$ ./hw 1</dev/null
object.Error: Bad file descriptor
----------------
5   hw                                  0x0000000109e4b765 extern (C) int
rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void
tryExec(scope void delegate()) + 45
6   hw                                  0x0000000109e4b719 _d_run_main + 457
7   hw                                  0x0000000109e4b548 main + 20
8   libdyld.dylib                       0x00007fff8e6107e1 start + 0
9   ???                                 0x

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Lionello Lunesu <lio+bugzilla lunesu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull



02:48:59 PDT ---
https://github.com/D-Programming-Language/druntime/pull/525

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




19:40:31 PDT ---


 https://github.com/D-Programming-Language/druntime/pull/525


Fixed up:
https://github.com/D-Programming-Language/druntime/pull/530

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344




Commits pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/bee1986bff7055bf2eb0d6fdf1dd44f5e56e03d6
Issue 10344 Exiting _Dmain should flush all FILE*s and return nonzero on
failure

https://github.com/D-Programming-Language/druntime/commit/2c88aa3d3e874f1ed5b13e0318791859df9c4dbb


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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 24 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10344


Lionello Lunesu <lio+bugzilla lunesu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



00:41:49 PDT ---
dawgfoto merged commit 2c88aa3 into D-Programming-Language:master  from
lionello:fix10344  4 minutes ago

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 24 2013