Re: egcs 10-31 and UnixWare

[Robert Lipe <robertl@dgii.com>]

[ 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