This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs 10-31 and UnixWare
[ Re: Program calling exit() in a function registered via atexit() ]
I asked one of the SCO engineers about this, and he confirms the
behaviour is as we suspected, though it is changed in future versions.
He offered:
Regarding the standard, the behavior is undefined when a
program calls exit() from an atexit()-registered function:
"If more than one call to the exit function is
executed by a program, the behavior is undefined."
in the description of exit in the current C standard.
I don't see this in my copy of Plauger's C library spec or in
SUSv2, but it's certainly believable.
> > Redhat 4.1/x86: Calls two. Calls one. Calls two. Call two. Repeats
> > until stack size hits 8Mb ulimit. Faults.
>
> I got the same result as Linux on Windows NT 4.0 with VC++ 5.0.
> However I can change Linux to whatever behaviorw which makes
> more senses.
>
> How about call everyone on the list and use the status in the
> last exit () call? BTW, it seems to be what happens on Solaris.
I'll leave that to you, H.J.
I think the OpenServer (which calls abort() in this case, grrr..)
option is to remove HAVE_ATEXIT from sco5.h and let the dtors be
run via .fini instead of via an exit callback. This I did in my
recent patch to gcc2 and egcs.
Alternately, should we discourage (disallow?) calling exit()
from destructors? If so, just changing the exit() in the
testcase in question to _exit() would sidestep the issue for
the testcase, thought it might still be an issue for the Real
World. Of course, if Linux and the other two OSes that H.J.
cited are indicative of the Real World, nobody does this
anyway....
It seems like loophole to restrain global destructors based on
undefined behaviour in atexit() when the programmer didn't call
atexit() - we used atexit() behind his back.
>From here, the language lawyers in the group can duke it out. :-)
RJL