 |
|
|
|
Actions
|
|
[ Date Prev][ Date Next][ Thread Prev][ Thread Next][ Date Index][ Thread Index]
Re: [cxx-abi-dev] Type mismatch in __cxa_atexit and __cxa_finalize
- To: Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
- Subject: Re: [cxx-abi-dev] Type mismatch in __cxa_atexit and __cxa_finalize
- From: Matt Austern <austern@xxxxxxxxx>
- Date: Mon, 1 Mar 2004 14:07:12 -0800
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
|
|