[cfe-dev] Language linkage of function type

[Richard Smith]

On Mon Jan 20 2014 at 7:42:39 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 20 January 2014 02:37, Stephan Bergmann <sbergman at redhat.com> wrote:
> > I am wondering why clang::FunctionType, unlike clang::FunctionDecl, does
> not
> > offer a function to determine its clang::LanguageLinkage.
> >
> > I am asking because in the C++ code
> >
> >   extern "C" { static void f(); }
> >
> > the FunctionDecl representing f has isExternC() return false (as the
> name of
> > function f has internal, not C language linkage), but the function's type
> > has C language linkage and I need to know about that in a plugin.
>
> I think it is just because it is not implemented yet. If I remember
> correctly, we only track language linkage of decls.


Right.

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.

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:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1555

... but I'm not sure if EWG has looked at this issue yet.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140122/720e92da/attachment.html>