digitalmars.D.bugs - [Issue 10344] New: Exiting _Dmain should flush all FILE*s and return nonzero on failure
- d-bugmail puremagic.com (39/39) Jun 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (27/27) Jun 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (18/39) Jun 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (20/54) Jun 13 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (21/21) Jun 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (15/17) Jun 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (26/27) Jun 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (14/42) Jun 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (25/35) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (19/37) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (25/39) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (9/14) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (16/22) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (14/14) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (28/49) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (12/23) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (8/11) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (29/29) Jun 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (12/13) Jun 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (26/31) Jun 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (10/10) Jun 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (8/9) Jun 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (13/13) Jun 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
- d-bugmail puremagic.com (12/12) Jun 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10344
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=10344 07:25:43 PDT ---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.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.oops, I meant stdout.flush(); stderr.flush();This can be opt-out also: int main() { .... try { fflush(NULL); } catch {} return 0; } So I'm OK with this.fflush doesn't throw.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: -------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.
Jun 13 2013
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=10344 PDT ---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.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.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
http://d.puremagic.com/issues/show_bug.cgi?id=10344 06:21:27 PDT ---But you are hijacking the return value, effectively declaring that stdout success is a critical error.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.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: -------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.
Jun 17 2013
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
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 outputMy 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 stdoutThe 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
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
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.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: -------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.
Jun 17 2013
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
http://d.puremagic.com/issues/show_bug.cgi?id=10344 13:31:35 PDT ---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 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.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.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.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.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.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
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=10344 02:32:54 PDT ---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: -------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.
Jun 18 2013
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
http://d.puremagic.com/issues/show_bug.cgi?id=10344 19:40:31 PDT ---https://github.com/D-Programming-Language/druntime/pull/525Fixed 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
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
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