[cxx-abi-dev] Type mismatch in __cxa_atexit and __cxa_finalize

Matt Austern austern at apple.com
Mon Mar 1 22:07:12 UTC 2004


On Feb 27, 2004, at 11:25 AM, Mark Mitchell wrote:

> Matt Austern wrote:
>
>> Maybe this is old news; I'm sure everyone who has implemented atexit 
>> in terms of __cxa_atexit must have noticed it already.
>
> I believe that GNU libc implemented both atexit and __cxa_atexit atop 
> some other interface, but I haven't looked in a long time.
>
>> The obvious fix would be to say that:
>>  1. atexit(f) invokes __cxa_atexit((void(*)(void*)) f, 0, 0).
>>  2. If you're passing __cxa_atexit a function that does take an 
>> argument, the parameter may not be 0.
>>  3. When __cxa_finalize invokes a function f on a parameter p, it 
>> should do the equivalent of:
>>      if (p)
>>         (*f)(p);
>>      else
>>        (*((void (*)(void)) f))();
>
> That's a reasonable approach, but point (2) worries me -- that might 
> represent a change for some existing implementations.
>
> An alternative would be to remove the explicit impliciation in the ABI 
> that atexit is implemented atop __cxa_atexit, and just indicate that 
> (a) the calls to the registered functions must be interleaved in the 
> appropriate way, and (b) __cxa_finalize called with a NULL DSO 
> parameter must call the functions registered with atexit.
>
> Thoughts?

I'm mildly nervous about point (2) also, but only mildly.  The number 
of compilers that use this ABI isn't huge, and it shouldn't be hard to 
confirm that there are no compilers that use a NULL data pointer.  I 
bet there are none.  And we now know there is one implementation that 
uses this technique.  So this is my very-slightly-preferred option.

But then, I also don't mind your alternative.  It's equally easy to 
specify, and it's only slightly harder to implement.

			--Matt




More information about the cxx-abi-dev mailing list