What does mean for a name or type to have a certain language linkage?

Question

According to (c) ANSI ISO/IEC 14882:2003, page 127:

Linkage specifications nest. When linkage specifications nest, the innermost one determines the langu

Answer 1

What does all this mean? For example, what linkage does the f2() function have, C or C++ language linkage?

extern "C" typedef void FUNC();
FUNC f2;
// the name f2 has C++ language linkage and the 
// function's type has C language linkage 

What you're calling the "f2() function" has two aspects to its linkage:

• the mangling or not of its name in the symbol table (which has C++ language linkage), and
• the C or C++ calling convention necessary should the function be called (C).

To call f2() you find its name aka symbol in the object file, which will be a mangled version of "function named f2 taking no arguments". You can verify this trivially by compiling the above code and inspecting the object (e.g. w/ GNU tools nm --demangle).

But to call the function, the conventions for pre- and post-conditions re register usage, stack setup etc. are those of a C functions. It is legal for C and C++ functions to have different calling conventions, and might be done - for example - to facilitate C++ exception handling.

Please explain the differences in the object file: a function's name with C language linkage and C++ language linkage.

• for C linkage, "f2" would be the symbol in the object file resulting from f2()
• for C++ linkage, some mangled version of "function named f2 taking no arguments" (for GNU, _Z2f2v which demangles to f2())

a function's type with C language linkage and C++ language linkage.

As discussed above, this is about the register/stack usage convention for calling the code at the function's address. This meta-information is not necessarily stored in the symbol table information of the object (and certainly isn't part of the symbol name key itself).

Further, because each function adopts one of the calling conventions, a compiler needs to know the calling convention to use when following a pointer to a function: with that insight, I think the remaining code in the question becomes clear.

There's an excellent discussion at http://developers.sun.com/solaris/articles/mixing.html - in particular I recommend the section Working with Pointers to Functions.

Answer 2

Language linkage is the term used for linkage between C++ and non-C++ code fragments. Typically, in a C++ program, all function names, function types and even variable names have the default C++ language linkage.

A C++ object code can be linked to another object code which is produced using some other source language (like C) using a predefined linkage specifier.

As you must be aware of the concept of name mangling, which encodes function names, function types and variable names so as to generate a unique name for them. This allows the linker to differentiate between common names (as in the case of function overloading). Name mangling is not desirable when linking C modules with libraries or object files compiled with a C++ compiler. To prevent name mangling for such cases, linkage specifiers are used. In this case, extern "C" is the linkage specifier. Let's take an example (c++ code mentioned here):

typedef int (*pfun)(int);  // line 1
extern "C" void foo(pfun); // line 2
extern "C" int g(int)      // line 3
...
foo( g ); // Error!        // line 5

Line 1 declares pfun to point to a C++ function, because it lacks a linkage specifier.

Line 2 therefore declares foo to be a C function that takes a pointer to a C++ function.

Line 5 attempts to call foo with a pointer to g, a C function, a type mis-match.

Diff in function name linkage:

Let's take two different files:

One with extern "c" linkage (file1.cpp):

#include <iostream>
using namespace std;

extern "C"
{
void foo (int a, int b)
{
    cout << "here";
}
}

int main ()
{
    foo (10,20);
    return 0;
}

One without extern "c" linkage (file2.cpp):

#include <iostream>
using namespace std;

void foo (int a, int b)
{
    cout << "here";
}

int main ()
{
    foo (10,20);
    return 0;
}

Now compile these two and check the objdump.

# g++ file1.cpp -o file1
# objdump -Dx file1

# g++ file2.cpp -o file2
# objdump -Dx file2

With extern "C" linkage, there is no name mangling for the function foo. So any program that is using it (assuming we make a shared lib out of it) can directly call foo (with helper functions like dlsym and dlopen) with out considering any name mangling effects.

0000000000400774 <foo>:
  400774:   55                      push   %rbp
  400775:   48 89 e5                mov    %rsp,%rbp
....
....
  400791:   c9                      leaveq 
  400792:   c3                      retq   

0000000000400793 <main>:
  400793:   55                      push   %rbp
  400794:   48 89 e5                mov    %rsp,%rbp
  400797:   be 14 00 00 00          mov    $0x14,%esi
  40079c:   bf 0a 00 00 00          mov    $0xa,%edi
  4007a1:   e8 ce ff ff ff          callq  400774 <foo>
  4007a6:   b8 00 00 00 00          mov    $0x0,%eax
  4007ab:   c9                      leaveq 

On the other hand, when no extern "C" is being used, func: foo is mangled with some predefined rules (known to compiler/linker being used) and so an application can not directly call it from it specifying the name as foo. You can however call it with the mangled name (_Z3fooii in this case) if you want, but nobody use it for the obvious reason.

0000000000400774 <_Z3fooii>:
  400774:   55                      push   %rbp
  400775:   48 89 e5                mov    %rsp,%rbp
 ...
...
  400791:   c9                      leaveq 
  400792:   c3                      retq   

0000000000400793 <main>:
  400793:   55                      push   %rbp
  400794:   48 89 e5                mov    %rsp,%rbp
  400797:   be 14 00 00 00          mov    $0x14,%esi
  40079c:   bf 0a 00 00 00          mov    $0xa,%edi
  4007a1:   e8 ce ff ff ff          callq  400774 <_Z3fooii>
  4007a6:   b8 00 00 00 00          mov    $0x0,%eax
  4007ab:   c9                      leaveq 
  4007ac:   c3                      retq   

This page is also a good read for this particular topic.

A nice and clearly explained article about calling convention: http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

Answer 3

As we all know in C/C++ code translation is composed of two principal phases: compilation and linking. When compiler generates object files it passes information to linker specifying in which object files given function is called or referenced. In C it is just like that, function has a name and matching definition.

// file1.c
void foo(void) {}

And after compilation file1.obj stores the code and information about the definition of the foo symbol.

But when C++ comes in the symbol names become more complicated. A function may be overloaded or be a member of a class. But the linker does not want to know it. To preserve simplicity and re-usability of older linkers it needs a single name whether foo is:

void foo(void) {}
void foo(int) {}
void ClassA::foo(void) {}

But it cannot be called just foo anymore so here comes name mangling. And we may get from the compiler some variations like foo_void, foo_int, foo_void_classa. And finally the linker is happy as all those look to it like simple symbols.

When we want to call the foo function compiled with the C compiler in C++ code we must tell the compiler that we want foo to be C style foo and not foo_void as C++ compiler might assume. It is done using:

extern "C" void foo();

Now the compiler knows that foo is compiled using C compiler and will pass information to the linker that this code calls foo. The linker will match it with the foo definition in file1.obj. So it's all I think.

Some other directives like cdecl or stdcall are Windows specific and tell how parameters in function calls are being passed. Yes, for C and C++ it is cdecl. But Windows API functions use stdcall - Pascal convention (simplicity and historically Microsoft once provided Windows dev environment in Pascal).

Answer 4

Every function, function type, and object has a language linkage, which is specified as a simple character string. By default, the linkage is "C++". The only other standard language linkage is "C". All other language linkages and the properties associated with different language linkages are implementation-defined.

Answer 5

"the name f2 has C++ language linkage" In C++ language linkage not only the name of the function defines it but also the type of it arguments and the return value. in this case you have: void f2(void); but you can define with it: void f2(int a); without conflict because the linkage will see them as different types, a thing you wouldn't be able to do in C language.

"the function's type has C language linkage" I don't know the details but I know the high level of it. Basically it makes a C++ compiled function linkable from C. If I remember correctly In C and in C++ the way the parameters are passed to a function is different. In this case the function f2 will pass the parameters as C compiler does this. this way the function will be linkable both from C and C++.

Answer 6

It has to do with the ABI (Application Binary Interface) of the program.

As an API specifies the the external interface of the source code of a program, an ABI specifies the external interface of the binary code of the program (the compiled version).

---

Originally, C functions simply had a few different forms. Something like

int foo(int);

would be prefixed by an underscore by the compiler, to form _foo, and then exported to be made available to other applications.

However, that wasn't enough. If you look at the Windows API, for instance, you will see things like:

DWORD CreateWindowW(...);        //Original parameters
DWORD CreateWindowExW(..., ...); //More parameters

This is because there's no way to distinguish between the overloads of a function simply by looking at the name of the function, so people started changing them by adding an Ex suffix (or the like).

This grew to be pretty ugly, and it still didn't allow for operator overloading, which was featured in C++. Because of this, C++ came up with name mangling, to put extra information in the name of the function, like the data types of its parameters, and making it something cryptic with lots of @ symbols.

It was all well, except that it wasn't completely standardized.

Of course, as new languages and compilers came about, each came up with its own scheme, some incompatible with others. So if you need to import or export an external function, you need to specify what kind of ABI the compiler should look for, hence the extern "C++" you have there.