atexit/static dtor interleaving

Jonathan Schilling jls at sco.com
Wed Aug 11 13:17:00 UTC 1999


> From owner-cxx-abi at corp.sgi.com Wed Aug 11 08:40:00 1999
> 
> >Based on a close (perhaps dubious) reading of 18.3, we decided that
> >the <cstdlib> std::atexit() may exist in a different world from
> >the <stdlib.h> ::atexit(); it does not have "additional behavior"
> >relative to the C standard library but instead has its own specification.
> >
> >Jonathan Schilling      SCO, Inc.       jls at sco.com
> 
> Jonathan, the way you have described this it sounds like an exercise in fine
> lawyering.
> But I'm sure you agree that the final criterion in these cases isn't whether you
> can squeak
> something by the standard, but whether the result is reasonable and useful to
> your customers.
> Is it SCO's position that ordering between C and C++ atexit() isn't useful?

I think it's our position that C++ atexit() isn't very useful, for all the
reasons that have been mentioned (interleaving with static destructions,
interdeterminate static construction/destruction order, and everything
falls apart when DSOs are explicitly unloaded).  

All other things being equal, yes, it's best if C and C++ atexit() 
interoperate together with the static destructions.  But we weren't willing 
to rework our C library atexit() mechanism to make this happen.

For what it's worth, my support mail files contain only one instance of 
anyone using C++ atexit() in an application, and no one has complained
about our partitioning of C and C++ atexit().

Jonathan Schilling		SCO, Inc.		jls at sco.com




More information about the cxx-abi-dev mailing list