Re: [RFC] libgfortran dll i/o redirection lossage caused by order-of-termination issue

[Andy Koppe <andy dot koppe at gmail dot com>]

2009/7/10 Dave Korn <dave.korn.cygwin@googlemail.com>:
> ÂI think the fortran implementation is entirely within its rights. ÂThe
> fortran runtime for the application exits via exit(), not _exit(), and so it
> expects its destructors to get run - and since _exit() doesn't run dtors, it
> expects them to be run before _exit().
>
> http://www.opengroup.org/onlinepubs/009695399/
>
> says clearly that first atexit() functions are run, then file descriptors are
> closed. ÂIt doesn't talk about C++ dtors of course

But the C++ standard does:

exit(int status)
    The function exit() has additional behavior in C++:

# First, objects with static storage duration are destroyed and
functions registered by calling atexit are called. Objects with static
storage duration are destroyed in the reverse order of the completion
of their constructor. (Automatic objects are not destroyed as a result
of calling exit().) Functions registered with atexit are called in the
reverse order of their registration. A function registered with atexit
before an object obj1 of static storage duration is initialized will
not be called until obj1's destruction has completed. A function
registered with atexit after an object obj2 of static storage duration
is initialized will be called before obj2's destruction starts.

# Next, all open C streams (as mediated by the function signatures
declared in <cstdio>) with unwritten buffered data are flushed, all
open C streams are closed, and all files created by calling tmpfile()
are removed.

# Finally, control is returned to the host environment. ...


Andy