exit, atexit and scope

[Ben Bacarisse]

On 15 nov, 23:43, Ben Bacarisse <[email protected]> wrote:

I am not talking to promote this style, but there is cases where this
is required like in "stack unwinding a-la-C++". You have a global
pointer pointing to a linked list of "stacked" pointers to automatic
variables holding critical resources and a proper implementation
should call their destructor before exit()ing. I am open to any
alternative, but the problem is not obvious.

My comment was just a general "avoid this" remark to other readers. I
assumed from your previous posts that you were probably looking into
some automatic C++-style cleanup implementation.

I can offer two ideas (you've probably thought of both!):

(1) Build you own "parallel" stack. Your objects get put here rather
than in automatic storage.

(2) Take over the implementation of exit (yes, not really permitted
but probably safe enough). Of course if you can insist that programs
use your version you don't need to take anything over. Your clean_exit
function can do the cleanup required before calling exit.

 

[Laurent Deniau]

My comment was just a general "avoid this" remark to other readers. I
assumed from your previous posts that you were probably looking into
some automatic C++-style cleanup implementation.

I can offer two ideas (you've probably thought of both!):

Right, I did ;-)

(1) Build you own "parallel" stack. Your objects get put here rather
than in automatic storage.

There is two problems with 1). It is inefficient (protection should be
nearly cost-less) so using automatic storage mean that protection is
equivalent to 2-3 machine code moves that is cheap. And you need non-
trivial code to handle bad_alloc-like exceptions since at the same
time you may try to 'push' protected ressources on a dynamically
allocated stack and you may need to enlarge the stack to store this
new reference. This in turn may throw a bad_alloc exception.

(2) Take over the implementation of exit (yes, not really permitted
but probably safe enough). Of course if you can insist that programs
use your version you don't need to take anything over. Your clean_exit
function can do the cleanup required before calling exit.

The code is part of the C Object System which is a general purpose
library to do (true) OO programming in C. I cannot guess all its
possible usage. And there is boundaries what I don't want to cross ;-)

a+, ld.

 

[Laurent Deniau]

7.20.4.3.2: First, all functions registered by the atexit function are
called, in reverse order of their registration.

The above implemetation does not conform to this.

Not sure what your objection is. It might be the meaning
of "first," as in Ben Bacarisse's discussion, in which case I
don't think c.l.c. is likely to arrive at any definitive answer.
But if (and I'm only guessing) you imagine that this exit() would
somehow fail to run the atexit() functions, my answer is that
they could be "called"[*] from the pre-main() code to which the
longjmp() returns:

switch (setjmp(_pre_main_jmpbuf)) {
case 0: /* first attempt */
_exit_status = main(argc, argv);
/* drop through */
case 1: /* exit() called */
_run_atexit_functions();
fflush(NULL);
_close_all_streams();
_remove_tempfiles();
/* drop through */
case 2: /* _Exit() called */
_really_exit(_exit_status);
}

[*] Please, no quibbles about whether "called" can be used
in connection with code that might not be written in C.

Looking at the C++ norm (18.3-5), it seems that this is the behavior
of the cstdlib exit() function of its standard library:

"For the execution of a function registered with atexit(), if control
leaves the function because it provides no handler for a thrown
exception, terminate() is called."

Which means that possibly existing handlers are bypassed and what
correspond to the code above (modulo static object destruction).

I think its wiser to forget this idea because I suspect that C++
adopted this behavior for good reasons (unknown to me) and some C
implementations may follow it for the same reasons. Another <off-
topic> point is that I cannot emulate the "good" behavior in threaded
environment, so better to not talk about it at all.

a+, ld.