From: eyal DOT ben-david AT aks DOT com
To: eliz AT is DOT elta DOT co DOT il
cc: djgpp AT delorie DOT com
Message-ID: <42256545.00598705.00@aks.com>
Date: Tue, 4 Nov 1997 18:37:26 +0200
Subject: Re: Writing to a file from dtor doesn't work!
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Precedence: bulk





On 11/4/97 1:27:57 PM Eli Zaretskii  wrote:

>On Mon, 3 Nov 1997, Nate Eldredge wrote:
>
>> I found the cause, but I still don't know if it's a bug. In
>> src/libc/ansi/stdlib/exit.c, __stdio_cleanup_hook is called before the
>> destructors. You guessed it, __stdio_cleanup_hook flushes all streams,
and
>> closes all except stdin, stdout, and stderr (cin, cout, cerr for C++).
If
>> this is not what's Supposed To Happen, it should be easy to change, just
>> move two lines of code. *Are* files Supposed to work in destructors?
>
>IMHO, people who use C++ extensively should answer this.  There might
>be conflicts with objects that use I/O streams and are destructed by
>global destructors.  DJ?
>
>Is it at all safe to assume that file handles beyond the 3 standard
>streams are available in the global destructor?  After all, they *are*
>run after `main' returned, so at least in principle, this is a
>never-never land for the application, no?
>
This is from the latest CD2 (december 96).  [ CD2 == Commity Draft ]

[start quote:
  3.6.3  Termination                                  [basic.start.term]

1 Destructors (_class.dtor_) for initialized objects of  static  storage
  duration (declared at block scope or at namespace scope) are called as
  a result of returning from main  and  as  a  result  of  calling  exit
  (_lib.support.start.term_).    These  objects  are  destroyed  in  the
  reverse order of the completion of their constructor or of the comple-
  tion  of  their  dynamic  initialization.  If an object is initialized
  statically, the object is destroyed in the same order as if the object
  was  dynamically  initialized.   For an object of array or class type,
  all subobjects of that object are destroyed before  any  local  object
  with  static  storage  duration initialized during the construction of
  the subobjects is destroyed.

end quote]

Note the line  "reverse order of the completion of their constructor ..."
since the constructor of the static global object in the sample is
completed AFTER the completion of the stream constructor, its destructor
should be called first. This assures that the file stream (and the file
handle)
is valid inside the destructor of the static global object.

I tested the sample also with Borland C++ 5.02 and it did write to the file

inside the destructor

I think that this sample should be checked with g++ on unix, to see if it
is DJGPP specific problem.

Eyal