[Bug c++/2316] g++ fails to overload on language linkage

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 10:46:51 UTC ---
(In reply to comment #22)
> Note that some things are painful to do right with extern "C". For instance,
> the __stoa helper takes as argument a pointer to a function with a type that
> depends on template arguments. As far as I can see, it is not possible to do
> that for extern "C" functions (I posted a question about that on clc++m
> yesterday), so that would mean rewriting this code differently.

I think you can do it with a alias-declaration in an extern "C" block:

extern "C" {
  template<typename T>
    using func_type = T (*)();
}

extern "C" void c() { }

template<typename T>
  void f( func_type<T> p ) { p(); }

int main()
{
  f(&c);
}

But yes, it's a bit of a hole in the type system that language linkage is part
of the type but can only be specified in some contexts and can't be deduced by
templates.  We could solve it with an alternative syntax for language linkage
using attributes:

  void f( [[extern(C)]] void (*p)() );

could be equivalent to:

  extern "C" {  typedef void (*func_type)();  }
  void f( func_type p );

so we could say:

  template<typename T, typename U>
    void g( [[extern(C)]] T (*p)(U));


Without alias-declarations, the tedious way to fix __stoa would be write an
extern "C++" forwarding function for each of the strtol, stroul, vsnprintf etc.
functions we need, and pass that forwarding function to the helper function
templates. That could be done with macros, and would still be simpler than
re-implementing the __stoa error-checking logic in each one.  Anyway, that is
probably straying off-topic for this PR.

> My guess is
> that making extern "C" functions usable would require a few DR, or extern "C"
> being part of the type will follow the example of "export" and be
> deprecated/removed (the second option is more likely, even if that's yet
> another change that hurts Oracle's compiler).

Clang++ and VC++ also "implement" this bug.  If it's fixed in G++ it would need
to be controlled by a switch, maybe with the current behaviour as the default
(but issuing a warning) for a couple of releases. As I said in c13, it could
break a lot of code, plenty of people don't even know that they shouldn't be
able to pass extern "C++" functions to C library APIs.