<div>On Mon Jan 20 2014 at 7:42:39 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20 January 2014 02:37, Stephan Bergmann <<a href="mailto:sbergman@redhat.com" target="_blank">sbergman@redhat.com</a>> wrote:<br>
> I am wondering why clang::FunctionType, unlike clang::FunctionDecl, does not<br>
> offer a function to determine its clang::LanguageLinkage.<br>
><br>
> I am asking because in the C++ code<br>
><br>
>   extern "C" { static void f(); }<br>
><br>
> the FunctionDecl representing f has isExternC() return false (as the name of<br>
> function f has internal, not C language linkage), but the function's type<br>
> has C language linkage and I need to know about that in a plugin.<br>
<br>
I think it is just because it is not implemented yet. If I remember<br>
correctly, we only track language linkage of decls.</blockquote><div><br></div><div>Right.</div><div><br></div><div>It would also break some amount of code if we started supporting this. For instance, the C++ standard requires that the standard library qsort function is overloaded to take extern "C" and extern "C++" function pointers, for instance, but glibc doesn't do so, and neither libstdc++ nor libc++ fixes this, so C++ code using qsort would likely be broken by such a change. The same thing probably happens in various other guises for other APIs that take function pointers.</div>
<div><br></div><div>There's a possibility that we might be able to introduce the rule in a more backwards-compatible fashion through a tweak to the rules:</div><div><br></div><div><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1555">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1555</a><br>
</div><div><br></div><div>... but I'm not sure if EWG has looked at this issue yet.</div><div><br></div><div>The upshot of all this is that C++ implementations/configurations that don't have different calling conventions for C and C++ tend to not implement this rule at all today (because implementing it provides basically no value to their users and breaks code).</div>