How does C's "extern" work?

Question

I have a C/C++ program that's a plugin to Firefox. Because it's a plugin, it has non-main entry points. Those entrypoints need to be compiled in C because otherwise they get name mangled.However, other functions are over-loaded, so they need to be C++. The solution is extern "C". That much I've already figured out.

However, if I extern "C" around the .c file, I get link errors because the C++ files got name mangled, but the calls in the .c file didn't. At least I THINK that's what's happening.

The solution APPEARS to be to put the extern "C" around the .h file. This SEEMS to mean that the names of the functions declared in the .h file aren't mangled, even when they're defined in the (presumably mangled) .c file.

However, it doesn't really make any sense to me why this would work. Is this a kludge? Am I setting myself up for a hard to find bug later? or is this the right way to solve this?

Answer 1

The least confusing thing (at least for me) to do is to make the declarations in the header match the function definitions. As other answers have mentioned, it's the declaration/prototype that matters most - the extern "C" linkage specification can be omitted from the function definition as long as the prototype has been 'seen' by the compiler already when it gets to the definition. However, personally I find it preferable and less potentially confusing to have the declarations and the definitions match, but that's a preference that other programmers might not share.

Note that you don't have to extern "C" everything in a header or implementation file - the extern "C" can be applied to a single name or to a group of names (by applying it to a block).

So, in your header you can have something like:

// entrypoints.h

#ifdef __cplusplus
// this opens an extern "C" block, but only if being included for a C++ compile
//  if this is being included in a C compile, the extern "C" bits won't be seen
extern "C" {
#endif

int foo(void);
int bar( void*);


#ifdef __cplusplus
// close the extern "C" block, but only if we started it in the first place
}
#endif

And your implementation of them:

// entrypoints.cpp

// Note: since this is a .cpp file, it's compiled as C++ so we
//  don't need the #ifdefs around the extern "C"

#include "entrypoints.h"

extern "C"
int foo(void)
{
    return 42;
}


extern "C"
int bar( void* p)
{
    return -42;
}

Answer 2

Extern "C" should apply to function prototype, so if you have separate prototype and implementation, put extern declaration around prototypes. Implementation, provided prototype is visible, will be extern as well and not mangled. It is not a bug.

Answer 3

This is not a kludge - this is how C/C++ compilers work. When the compiler compiles a file that uses your library, it checks the .h files for declarations of functions and globals. Hence, you wrap the .h files with extern "C" to avoid name mangling.

Answer 4

Only the declaration of the functions needs to be wrapped in extern "C". Once the function has been declared, the compiler knows that its name shouldn't be mangled. Since most of the time your function declarations are in your header file, wrapping the extern "C" around your header or around the include of it should work fine.

Answer 5

It is already enough when you only extern "C" the entities you need to be externally visible. You can make a standard cc/cpp/cxx/... file, but cherry pick C-names:

class Foo {};

extern "C" int someInterfaceFun () {
    Foo foo;
    return 0xFEED;
}

Answer 6

You seem to be overly obsessed with this "putting around"/"wrapping" thing. At the fundamental level you are not normally supposed to put extern "C" "around" anything. extern "C" is a declaration specifier, a linkage specifier, which assigns C-linkage to a specific name. Again, it applies to specific individual names. At the fundamental level you are supposed to declare each of your C++-to-C interface functions in your header file as extern "C", as in

extern "C" void foo(void);
extern "C" char bar(int);

Later you can specify the same extern "C" to the function definitions in the implementation file

extern "C" void foo(void) {
  /* whatever */
}

extern "C" char bar(int) {
  /* whatever */
}

But strictly speaking, it is not really necessary to repeat extern "C" in the definition, since if you have already declared your function as extern "C", this linkage specification basically gets "inherited" by the definition as well (assuming the declaration is made before the definition in this translation unit). In other words, these function names will not get "mangled", since the compiler knows already, that these names are declared as extern "C" names.

That's all there's to it. Now, as you already know, you can also use a {} form of extern "C" that lets you wrap the entire section of a file into the extern "C" region. Well, that's just a nice side-feature of extern "C" that can save you some typing. But normally, you should not just indiscriminately enclose entire files into the extern "C" region - this is akin to shooting sparrows with a cannon. The specifier is supposed to be applied selectively, only to the names that really need C-linkage. Actually, in many cases you might (and will) have a dedicated C-interface header file that contains only declarations that are supposed to have C-linkage. Putting the extern "C" around the entire header file in this case is normal practice, but in general case you should use it more carefully and make sure you are not covering with a blanket extern "C" specifier something that is not supposed to have C-linkage.

Answer 7

if the .c file includes the .h file and the function prototypes in the .h file are in an extern "C" block, everything should be ok. The functions declared as extern "C" won't have mangled names, all the other functions will.