http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #43 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-04
12:51:55 UTC ---
(In reply to comment #40)
> Great! If all existing code is accepted with a warning that provides backwards
> compatibility, but also allows conforming code to correctly overload on
> language linkage - that sounds ideal.
Well, not all existing code, just the most common ones. For instance:
template<class>struct is_fun1{static const bool value=false;};
template<class F,class T>struct is_fun1<F(T)>{static const bool value=true;};
will answer false for an extern "C" function type, and I am not sure how I
could make it return true without breaking valid code too much (and you can
call template<class F,class T>void f(F(T)); with an extern "C" function, but it
has lower priority than template<class T> void f(T); or even void f(...);).
But most uses in common code seem to be fine (it is even more lenient than
sunCC, which fails to compile gcc because of extern "C"). Note that accepting
these broken codes does imply we do the wrong thing on some valid code but I am
hoping not too much. As a guiding principle, I tried to allow conversions only
when there would be an error otherwise.
> IMHO the warning should be controllable by something such as
> -Wlanguage-linkage
> (since there will be lots of warnings in some codebases, so it needs to be
> possible to use -Wall but disable these warnings) and the conversion should be
> rejected with -pedantic-errors.
Agreed, there's a lot of cleanup to do...
(In reply to comment #41)
> I would expect a lot of code to trigger this warning. It is quite common
> to pass the address of a static member function to pthread_create but since
> there is no way to make a static member function 'extern "C"', I can't see
> how to do that without major contortions. I'm rather sure that this will
> turn out to be an unpopular warning :-)
libstdc++ does something like that in one place. As Jonathan told earlier, it
would make sense to overload pthread_create so it can take a C++ function. The
easiest way not to have the warning is to use a cast (not that this is very
standard...).
As for the popularity... I am still not sure we actually want to do this at
all, this is a proof of concept to help make a decision.
