Re: p2736.C Is dtor order guaranteed?

[mrs at wrs dot com (Mike Stump)]

> From: hjl@ocean.lucon.org (H.J. Lu)
> To: oliva@dcc.unicamp.br (Alexandre Oliva)
> Date: Mon, 20 Jul 1998 12:33:49 -0700 (PDT)
> Cc: robertl@dgii.com, egcs@cygnus.com

> The current implementation is wrong. We have to put the destructors
> for local static variables onto __DTOR_LIST__.

> Otherwise, we will also run into problems with dlopen/dlclose. The
> current scheme uses atexit.

> It may put a dlclosed function on the exit list.

> One way to fix all these is

> 1. egcs reserves a slot on __DTOR_LIST__ for the destructor of the
> local static variable. We can mark it as -1 so that
> __do_global_dtors_aux won't run it.
> 2. Put an auxiliary constructor of the local static variable on
> _CTOR_LIST__ to record some information for the real constructor.
> 3. The real constructor of the local static variable will put the
> destructor in the reserved slot on __DTOR_LIST__ and rearrange
> the order of __DTOR_LIST__ if necessary.

If you reread this, cleaning it up some and fixing a few bugs, you
wind up with a per module cleanup list, that has the form of a list of
cleanup actions per module.  Having the space for the list statically
allocated is good, I like that.

This can be made to work.  Also, one will want to use 0, not -1.  The
current structure uses 0 it appears and when speaking of pointers, 0
makes a better unique value than -1.

The only other questions are ordering the total ordering, and atexit
ordering.  I think that atexit style actions should be interleaved
with the normal dtors.  The standard said, last I read it, that they
were separate.  I think this was a mistake and that in the five year
re-release of the standard we can fix it there.  I think g++ should
get it right from the start.

For total ordering, the dtor calls have to be interleaved across
modules in the case that you want to fire off all the dtors, and in
the case of firing off dtors for one module, you want to fire just the
dtors for that one module.

Fixing any of this code (sco coff type problems excluded) without
doing the complete job just means that you break someone's idea of
what should be while giving a different set of people what they
wanted, as bad trade.  Better to just offer stability and
predictability, if you're not willing to fix it.