Static linkage and extern "C"

[Mark A. Gibbs]

I have a question about mixing C and C++.

In a C++ translation unit, I want to define a function with internal
linkage and C calling convention. Here's a sample of what I want to do:

// main.cpp

// This is defined in a C module
extern "C" void fake_qsort(void*, std::size_t, std::size_t,
int (*compare)(const void*, const void*));

namespace {

int compare_func_(const void*, const void*);

} // anonymous namespace

int main()
{
foo bunch_of_foos[100];
// ... fill bunch_of_foos somehow

// Fake qsort has the same signature as std::qsort
// but is extern "C"
fake_qsort(&bunch_of_foos, sizeof(bunch_of_foos), sizeof(foo),
compare_func_);

return 0;
}

int compare_func_(const void*, const void*)
{
// ...
}

In a C++ translation unit, compare_func_() will have C++ calling
convention by default, unless I explicitly declare it extern "C". And
the fake_qsort() function is expecting a function with C calling convention.

I know this is illegal:
extern "C" static int compare_func_(const void*, const void*);

And this *seems* to be legal:
namespace {
extern "C" int compare_func_(const void*, const void*);
} // anonymous namespace

But does it do what I want (give me a function with internal linkage but
C calling convention)?

What about this?
extern "C" {
static int compare_func_(const void*, const void*);
}

Or even this?
extern "C" {
namespace {
int compare_func_(const void*, const void*);
} // anonymous namespace
}

Mark

 

[Branimir Maksimovic]

I have a question about mixing C and C++.

In a C++ translation unit, I want to define a function with internal
linkage and C calling convention. Here's a sample of what I want to do:

// main.cpp

// This is defined in a C module
extern "C" void fake_qsort(void*, std::size_t, std::size_t,
int (*compare)(const void*, const void*));
.......
In a C++ translation unit, compare_func_() will have C++ calling
convention by default, unless I explicitly declare it extern "C". And the
fake_qsort() function is expecting a function with C calling convention.

Don't bother with that. extern "C" does not really specify calling
convention,
(it might) but does not specify *which* C calling convention if more then
one are available
extern "C" is practically only usefull to tell compiler not to mangle
symbols when
exporting functions, but if you do need to specify calling
convention you'll do it with implementation specific extensions anyway,
in which case you don't need extern "C". You have to use it if compiler
spits an error, which happens on some implementations.

I know this is illegal:
extern "C" static int compare_func_(const void*, const void*);

And this *seems* to be legal:
namespace {
extern "C" int compare_func_(const void*, const void*);
} // anonymous namespace

But does it do what I want (give me a function with internal linkage but C
calling convention)?

No. extern "C" function's can't be overloaded, neither namespace affects
anything .You get exactly the same symbol with or without namespace.

What about this?
extern "C" {
static int compare_func_(const void*, const void*);
}

It's an error, logical if you want.

Or even this?
extern "C" {
namespace {
int compare_func_(const void*, const void*);
} // anonymous namespace
}

Same thing . you want to export function name and to hide it in same time
This simply shows that extern "C" wants to do two things with one blow,
but fails both.
You need specifier both for calling convention and for name mangling
in real implementations.
So just drop extern "C" and if it works, ok, let it be, and #ifdef
implementations
where that is forced.
Final word, is that compiler might use different calling convention when
calling C++ and different when calling C, in which case extern "C" does
help, but that is nothing that can be fixed with switch or two

Greetings, Bane.

 

[Branimir Maksimovic]

Final word, is that compiler might use different calling convention when
calling C++ and different when calling C, in which case extern "C" does
help, but that is nothing that can be fixed with switch or two

can't

 

[Branimir Maksimovic]

It's an error, logical if you want.

But not compiler error. It declares C function with internal linkage!

Gosh, one learns something new every day.

 

[Branimir Maksimovic]

But not compiler error. It declares C function with internal linkage!

Gosh, one learns something new every day.

So this is the case when
namespace {
void f();
}

can't replace:

static void f();

 

[Greg Comeau]

So this is the case when
namespace {
void f();
}

can't replace:

static void f();

Say again?

 

[Mark A. Gibbs]

Don't bother with that. extern "C" does not really specify calling
convention,
(it might) but does not specify *which* C calling convention if more then
one are available
extern "C" is practically only usefull to tell compiler not to mangle
symbols when
exporting functions, but if you do need to specify calling
convention you'll do it with implementation specific extensions anyway,
in which case you don't need extern "C". You have to use it if compiler
spits an error, which happens on some implementations.

I'm a little confused. "Linkage-specification" does not mean the same
thing as "calling convention"? Or is the linkage specification just a
part of the calling convention (or is the calling convention just a part
of the linkage specification)? The standard seems to tell me that a
linkage-specification includes a calling convention (among other things,
in 7.5.1).

And if linkage specification is not the same as calling convention,
doesn't that mean that for a given a compiler, the calling convention
used for C and C++ must be the same (otherwise you couldn't mix C and
C++ code)?

And if the calling convention is the same for C and C++ functions, then
why are these two function pointers different?

extern "C" void (*pf_c)(void);
extern "C++" void (*pf_cpp)(void);

(If I'm reading the standard right, there is a difference between the
two, and name mangling doesn't matter to function pointers.)

No. extern "C" function's can't be overloaded, neither namespace affects
anything .You get exactly the same symbol with or without namespace.

I don't see what that has to do with overloading functions. And I don't
see what you're saying about getting the same symbol with or without the
namespace.

The way I see it is that this...

void foo()
{
}

.... defines a function that is externally visible with C++ linkage (when
compiled in C++). This...

namespace {
void foo()
{
}
} // anonymous namespace

.... defines a function that is not externally visible with C++ linkage.
This...

extern "C" void foo()
{
}

.... defines a function that is externally visible with C linkage. So
logically, this...

namespace {
extern "C" void foo()
{
}
} // anonymous namespace

.... should define a function that is not externally visible with C
linkage. No?

Same thing . you want to export function name and to hide it in same time
This simply shows that extern "C" wants to do two things with one blow,
but fails both.

'extern "C"' doesn't necessarily export the function (if I'm reading
this right). It would get exported anyway by default. 'extern
"anything"' tells the compiler/linker the calling convention (for
functions), and the format for the names of variables or functions with
external linkage, among other things. To me that implies that you should
be able to create 'extern "anything"' with *internal* linkage. It's
functionally the same thing as something with external linkage, except
the symbols aren't externally visible.

You need specifier both for calling convention and for name mangling
in real implementations.
So just drop extern "C" and if it works, ok, let it be, and #ifdef
implementations
where that is forced.
Final word, is that compiler might use different calling convention when
calling C++ and different when calling C, in which case extern "C" does
help, but that is nothing that can be fixed with switch or two

So... there is no difference between 'extern "C"' and 'extern "C++"' for
calling conventions, but there might be. And I don't need the 'extern
"C"' linkage specifier, but I might. And if I do, I really don't,
because I can use compiler settings to make it all go away.

All that sounds a little evasive and silly. Either it's necessary or
it's not, and if it is, then the question is still how to do it. If it
makes no difference on most implementations, great, but if I can write
one set of code that works (or at least that's legal C++, then we can
deal with broken compilers), without having to use conditional
compilation, then that seems to be the way to go.

Mark

 

[Branimir Maksimovic]

I'm a little confused. "Linkage-specification" does not mean the same
thing as "calling convention"?

No. calling convention is part of linkage specification.

Or is the linkage specification just a

part of the calling convention (or is the calling convention just a part
of the linkage specification)?

The opposite.

The standard seems to tell me that a

linkage-specification includes a calling convention (among other things,
in 7.5.1).
Yes.


And if linkage specification is not the same as calling convention,
doesn't that mean that for a given a compiler, the calling convention
used for C and C++ must be the same (otherwise you couldn't mix C and
C++ code)?

No. calling convention should be there in linkage specification.
Problem is that extern "C" assumes only one possible calling
convention.It is simply not descriptive enough.

(If I'm reading the standard right, there is a difference between the
two, and name mangling doesn't matter to function pointers.)


I don't see what that has to do with overloading functions.

Overloaded funcions have different symbols.

And I don't

see what you're saying about getting the same symbol with or without the
namespace.

well, linker searches for symbols in object files.
if you write namespace One{ void f(){} } namespace Two { void f(){} }
you get two different functions.
but
namespace One { extern "C" void f(){} }
namespace Two { extern "C" void f(){} }
refer to same function "f" and you'll get same symbol for both
of them which produces linker error.
So namespaces does not affect extern "C" at all.

The way I see it is that this...

void foo()
{
}

... defines a function that is externally visible with C++ linkage (when
compiled in C++). This...

namespace {
void foo()
{
}
} // anonymous namespace

... defines a function that is not externally visible with C++ linkage.

No. it defines foo with external linkage. anonymous namespace simply
generates unique identifier , which is unkown.
you need "static" to specify internal linkage.

This...

extern "C" void foo()
{
}

... defines a function that is externally visible with C linkage. So
logically, this...

namespace {
extern "C" void foo()
{
}
} // anonymous namespace

... should define a function that is not externally visible with C
linkage. No?

No. namespaces does not affect linkage nor extern "C" symbols.

'extern "C"' doesn't necessarily export the function (if I'm reading
this right). It would get exported anyway by default. 'extern
"anything"' tells the compiler/linker the calling convention (for
functions), and the format for the names of variables or functions with
external linkage, among other things.

No only two defined things are extern "C" for C linkage
and extern "C++" for C++ linkage, other literals can be
anything to implementation.

To me that implies that you should

be able to create 'extern "anything"' with *internal* linkage.

Problem is that that keyword "extern " is used to specify external
linkage. Therefore you need extern "C" { static void f(); }
to specify internal linkage.

It's

functionally the same thing as something with external linkage, except
the symbols aren't externally visible.

Or there are non of them. function with internal linkage does not need
symbol at all.

So... there is no difference between 'extern "C"' and 'extern "C++"' for
calling conventions, but there might be. And I don't need the 'extern
"C"' linkage specifier, but I might. And if I do, I really don't,
because I can use compiler settings to make it all go away.

All that sounds a little evasive and silly. Either it's necessary or
it's not, and if it is, then the question is still how to do it. If it
makes no difference on most implementations, great, but if I can write
one set of code that works (or at least that's legal C++, then we can
deal with broken compilers), without having to use conditional
compilation, then that seems to be the way to go.

Problem is that extern "C" is not guaranteed too work even if
compiles and links ok. You must know which calling convention
library you call(or calling code) use.
And if compiler does not use *that* calling convention
even if you specify extern "C", then you have to do non portable
stuff anyway.
I didn;t saw any compiler that use something like
extern "mangle_this_way_and_call_that_way_thing",
,rather, extern "C" is used to declare/define C function
within C++ code.
Strange enough it is not defined how to specify linking
with other C++ compiler, but it is assumed you can link with
C compiler

Greetings, Bane.

 

[Mark A. Gibbs]

Problem is that that keyword "extern " is used to specify external
linkage. Therefore you need extern "C" { static void f(); }
to specify internal linkage.

I thought you said that was illegal. If it's legal, and if it creates a
static extern "C" function, then that's what I need. Is that legal, and
is that what it's supposed to do?

Mark

 

[Branimir Maksimovic]

I thought you said that was illegal.

Oh, I corrected that in follow up post to myself

If it's legal, and if it creates a

static extern "C" function, then that's what I need.

Yes.

Is that legal, and

is that what it's supposed to do?

Of course, yes.

Greetings, Bane.

 

[Mark A. Gibbs]

Excellent! Thank you!

Mark