http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30
12:17:47 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
>
> > We could solve it with an alternative syntax for language linkage
> > using attributes:
> >
> > void f( [[extern(C)]] void (*p)() );
>
> Is that where attributes go? That must be inconvenient for functions returning
> function pointers. Or does it have some kind of "scope"?
I probably have the syntax wrong, I wanted that attribute to apply to the
parameter p, but for a function poiner maybe it should be:
void f( void (*p)() [[extern(C)]] );
And for a function pointer return type my attempt would be
void (* ugly(int)[[extern(C++)]] )() [[extern(C)]] ;
i.e.
extern "C" { typedef void (*c_func)() }
extern "C++" { c_func ugly(int); }
Maybe.
> My guess is that we are supposed to use extern "C" functions very rarely and
> only in very specific contexts where it doesn't matter so much if you can't do
> all the meta-programming stuff.
I did suggest to the POSIX C++ WG that there should be extern "C++" overloads
of pthread_create, pthread_atfork etc. just as we have overloads of qsort and
bsearch taking pointers to extern "C++" functions, which would allow existing
code that relies on this bug to just work without changes. I was going to
submit a proposal along those lines, but that WG seemed to fizzle out and I
never finished the paper. I probably still have it on an old hard drive on a
shelf somewhere.
