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