extern "C" ... again

Hello all,

I've spent a couple of hours reading topics on name mangling or name
decoration and the use of extern "C".
First, let me try to summarize what I think I have learned so far:
There is no standard or convention on how and when to use name
mangling. It is up to the "producer" of compiler and linker to decide.
Even for C++, there is no rule how function overloading and other
stuff is to be achieved, though it is commonly achieved through name
mangling.
Furthermore, name mangling is not an invention that came along when
there started to be object oriented programming or even C++ as a more
specific example. It has been there with good old standard C in a more
simple form (using underscore, at-sign and numbers left and/or right
of the function name).
I haven't yet found any statement on whether the old-style C name
mangling has any rule to it. Because if it doesn't, I have an
important question.

If I declare a function in a library as <extern "C">, it will revert
to old-style C name mangling. Though the <extern "C"> is not primarily
about name mangling, it is part of what it does (if the C++ compiler
does the more elaborate name mangling that is).
However, if there is no rule to old-style C name mangling, how is the
linker to find the referred function? Imagine I use a 3rd party
library which has been built with a different compiler/linker, is it
still enough to specify <extern "C"> when using this library?

Some enlightenment would be highly appreciated!

Thanks in advance,
regards,
Pelle.

Victor
Thu Jul 24 08:17:23 CDT 2008

Pelle wrote:
> [..] if there is no rule to old-style C name mangling, how is the
> linker to find the referred function? Imagine I use a 3rd party
> library which has been built with a different compiler/linker, is it
> still enough to specify <extern "C"> when using this library?

Name mangling follows a convention. The names are not random, there is
some logic to it, do you agree? It's not impossible to imagine that the
convention can be put in writing by the compiler developer and shared
with other developers, yes? Let's take an opposite and imagine what
would happen if it were true. What if car manufacturers instead of
using the same 12 volts for their electrical systems would each use
something different, 10 volts for one, 16 volts for another, 13.33 volts
for the third and so on? Doesn't make sense, does it?

On the same operating system the software developers follow the
recommendations of the OS developers when it comes to establishing their
conventions. Take dynamic libraries for example. Windows is based on
those. Functions in them have to have at least the ordinal number to be
accessible from outside. Next, take static libraries. Development of
stand-alone executables can be done without them, but why would anyone
want to go to so much trouble? So, the OS manufacturer supplies at
least the libraries to interface with the OS functionality. Now, if the
compiler/linker is capable of using those libraries, why not make those
requirements a convention and let any library to be usable in the same way?

Example: Intel C/C++ compiler follows Microsoft's convention for name
mangling, so the object modules it produces are fully compatible with
what Microsoft C/C++ compiler expects (and vice versa).

Not sure if this answers your question. If not, ask more question, I guess.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Igor
Thu Jul 24 08:16:57 CDT 2008

"Pelle" <pelle1911@gmx.de> wrote in message
news:6e38e69d-7f84-4178-9b78-ce6364db3eac@59g2000hsb.googlegroups.com
> First, let me try to summarize what I think I have learned so far:
> There is no standard or convention on how and when to use name
> mangling. It is up to the "producer" of compiler and linker to decide.
> Even for C++, there is no rule how function overloading and other
> stuff is to be achieved, though it is commonly achieved through name
> mangling.
> Furthermore, name mangling is not an invention that came along when
> there started to be object oriented programming or even C++ as a more
> specific example. It has been there with good old standard C in a more
> simple form (using underscore, at-sign and numbers left and/or right
> of the function name).

This "more simple form" is usually referred to as name decoration, to
distinguish it from C++-style name mangling.

> I haven't yet found any statement on whether the old-style C name
> mangling has any rule to it.

The documentation on calling conventions also describes name decoration.
See e.g.

http://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx

This is still compiler-specific - there's no standard saying names must
be decorated this way.

> If I declare a function in a library as <extern "C">, it will revert
> to old-style C name mangling. Though the <extern "C"> is not primarily
> about name mangling, it is part of what it does (if the C++ compiler
> does the more elaborate name mangling that is).

In practice, it _is_ primarily about name mangling.

> However, if there is no rule to old-style C name mangling, how is the
> linker to find the referred function?

Linker doesn't know nor care about name decoration or mangling rules.
All it has to do is to match a symbol in one .obj file to the same
symbol in another. It doesn't care whether the symbol is XYZ or _XYZ@12
or XYZ$ClassName$int (not a real example of name mangling). It's the
compiler's job to mangle or decorate the names in the same way in all
.obj files.

> Imagine I use a 3rd party
> library which has been built with a different compiler/linker

If you mean static library (.lib file), chances are high it won't work
with your compiler/linker, whether you use extern "C" or not. And not
only because of different name decoration rules. E.g. there's no
standard that dictates the precise binary layout of a struct: two
different compilers, seeing the same definition, may put the same field
at different offsets.

By the way, linker is not used when building a static library.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Pelle
Thu Jul 24 08:54:04 CDT 2008

On 24 Jul., 15:17, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> Pelle wrote:
> > [..] if there is no rule to old-style C name mangling, how is the
> > linker to find the referred function? Imagine I use a 3rd party
> > library which has been built with a different compiler/linker, is it
> > still enough to specify <extern "C"> when using this library?
>
> Name mangling follows a convention.
[...]
> On the same operating system the software developers follow the
> recommendations of the OS developers when it comes to establishing their
> conventions. =A0Take dynamic libraries for example. =A0Windows is based o=
n
> those. =A0Functions in them have to have at least the ordinal number to b=
e
> accessible from outside. =A0Next, take static libraries. =A0Development o=
f
> stand-alone executables can be done without them, but why would anyone
> want to go to so much trouble? =A0So, the OS manufacturer supplies at
> least the libraries to interface with the OS functionality. =A0Now, if th=
e
> compiler/linker is capable of using those libraries, why not make those
> requirements a convention and let any library to be usable in the same wa=
y?

Dear Victor,

thanks a lot for your reply. It is definately leading me towards
solution of my question.
I had already started wondering, what kind of mystical magic had been
done to enable different languages to call the OS API. In fact, I was
thinking about adding that question (well, somewhat like that) to my
primary post.

Let me see what I got...
So, there is a convention, not a standard or rule. However, this
convention is somewhat like an unwritten law, since you don't get
anywhere without it. More so, the convention is not based on a
language or language implementation, but rather on the OS.
Now this is really a step forward in understanding those interfaces.

But if so, why is every post I have read on interfacing different
languages, including C and C++ so intent on claiming that there is no
standard as to how it is done and it's most likely to encounter
incompatibilities (like the different voltages on car-electricity you
mentioned)?
Well, maybe it's a bit like some (very few) old fashioned cars and
motorcycles, which matter of fact don't use 12V power, but rather 6V.
They do exist, because it's not required to have them at 12V, but they
are very few and can be neglected!?

If you don't mind, please take the time for one more answer.

Regards,
Pelle.

Pelle
Thu Jul 24 09:08:10 CDT 2008


Dear Igor Tandetnik,

thanks for replying. Please see below for further questions.

On 24 Jul., 15:16, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> "Pelle" <pelle1...@gmx.de> wrote in message
>
> news:6e38e69d-7f84-4178-9b78-ce6364db3eac@59g2000hsb.googlegroups.com
>
> This "more simple form" is usually referred to as name decoration, to
> distinguish it from C++-style name mangling.

Uh... I had thought "name mangling" is more of a commonly used term
that has a more scientific but less commonly used equivalent, which is
name decoration. At least that's what I had gathered from my previous
readings.

> The documentation on calling conventions also describes name decoration.
[...]
> This is still compiler-specific - there's no standard saying names must
> be decorated this way.

Which is just about what I had intended to say. There's no rule (at
least at language level specification).

> > Imagine I use a 3rd party
> > library which has been built with a different compiler/linker
>
> If you mean static library (.lib file), chances are high it won't work
> with your compiler/linker, whether you use extern "C" or not. And not
> only because of different name decoration rules. E.g. there's no
> standard that dictates the precise binary layout of a struct: two
> different compilers, seeing the same definition, may put the same field
> at different offsets.

Ok, I get that. A static library is always specific to the programming
environment it has been created with. But there's more. Let me put it
this way: On the windows platform (sorry this is becoming OS specific)
pretty much any major programming language can interface with the
system API, which is contained in DLLs. Now, if this would require a
static import library, I would understand that this contains the
interface to the DLL to match the language to the internal style of
the DLL. But that's not the case. There's also dynamic linking, that
can reference functions from DLLs without an import library. Now, how
_can_ that work?

Thanks for your patience,
regards,
Pelle.

Victor
Thu Jul 24 09:15:59 CDT 2008

Pelle wrote:
> [..]
> Let me see what I got...
> So, there is a convention, not a standard or rule. However, this
> convention is somewhat like an unwritten law, since you don't get
> anywhere without it. More so, the convention is not based on a
> language or language implementation, but rather on the OS.
> Now this is really a step forward in understanding those interfaces.
>
> But if so, why is every post I have read on interfacing different
> languages, including C and C++ so intent on claiming that there is no
> standard as to how it is done and it's most likely to encounter
> incompatibilities (like the different voltages on car-electricity you
> mentioned)?

I would hazard a guess that you get a very generic answer to your quite
generic question. What's governing the compiler development for those
languages? Why, their Standards, of course. Is there anything written
in the Standards of any of the two languages about how such interfacing
is to be done at the compiler level? Of course not. It's left to the
compiler implementors. Why so? Because establishing rules that cannot
be followed by all would put an undue strain on the development of
compilers and go against the principle to allow as wide spread of the
language as possible.

If you look at the history of many popular compilers, you will most
likely see a tendency to keep the convention as long as possible with
all the benefits and drawbacks of allowing the backward compatibility.
Of course, you will also find instances when such conventions had to
change and force libraries and code that uses them to be recompiled.
It's not frequent, but I am sure it has happened. I bet you that nobody
can tell you with 100% certainty how those interfaces work (although the
interfaces has probably worked the same way for quite a few years now)
because it implies the promise of how they will work in the future,
which, in the case of C and C++ interoperability, cannot be made.

> Well, maybe it's a bit like some (very few) old fashioned cars and
> motorcycles, which matter of fact don't use 12V power, but rather 6V.
> They do exist, because it's not required to have them at 12V, but they
> are very few and can be neglected!?

I am certain that you can find a piece of a still-working system with
the source and libraries it was built from, but it will be
unrecognizable by modern compilers and linkers. Stuff does become
obsolete, you know; faster in our field than anywhere else.

> If you don't mind, please take the time for one more answer.

I don't mind. If I am unavailable to respond, I am sure your questions
are going to be answered by others, often more qualified people than
yours truly.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Giovanni
Thu Jul 24 09:11:09 CDT 2008

[Pelle]

> But if so, why is every post I have read on interfacing different
> languages, including C and C++ so intent on claiming that there is no
> standard as to how it is done and it's most likely to encounter
> incompatibilities (like the different voltages on car-electricity you
> mentioned)?

The problem is not only the name mangling. I think that the problem is also
the implementation of the C++ objects that you are passing at interfaces.

For example, if you use VS2008, and you are passing C++ STL objects at DLL
boundaries, you must be sure that both the .exe and the DLL use the same
values for settings like _HAS_ITERATOR_DEBUGGING.
This is because if that macro is defined, the structure (including memory
size) of STL objects like std::vector or other containers is different from
the case in which _H.I.D. is not defined.
So, we are in the case of the *same* C++ compiler (VS2008) - so same fixed
name mangling rules - but different settings of preprocessor macros,
influecing object implementation.

If you need more decoupling and more language and compiler independence, you
should consider COM technology (not trivial to learn, but well designed as a
common binary format to allow interoperation of different compilers and
languages).

Giovanni

Igor
Thu Jul 24 10:20:50 CDT 2008

Pelle <pelle1911@gmx.de> wrote:
> On the windows platform (sorry this is becoming OS specific)
> pretty much any major programming language can interface with the
> system API, which is contained in DLLs.

Because their respective vendors enabled it. The OS specifies a de-facto
binary standard (application binary interface, ABI). Vendors make their
tools conform - or they don't get to play in Windows market.

A traditional DLL interface is C-style (no classes or other C++
features), the function names are not decorated in any way, and most
functions use __stdcall calling convention. To produce such a DLL with
VC compiler, you need to write a .DEF file listing all functions you
want to export.

> Now, if this would require a
> static import library, I would understand that this contains the
> interface to the DLL to match the language to the internal style of
> the DLL.

I'm not sure what you mean by "internal style" of a DLL. I'm not
familiar with the term.

> But that's not the case. There's also dynamic linking, that
> can reference functions from DLLs without an import library. Now, how
> _can_ that work?

What precisely do you perceive as a problem that would prevent it from
working? I don't understand your concerns.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Pelle
Thu Jul 24 11:16:56 CDT 2008


Dear Igor Tandetnik,

thanks again. Please read below...

On 24 Jul., 17:20, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> Pelle <pelle1...@gmx.de> wrote:
> > On the windows platform (sorry this is becoming OS specific)
> > pretty much any major programming language can interface with the
> > system API, which is contained in DLLs.
>
> Because their respective vendors enabled it. The OS specifies a de-facto
> binary standard (application binary interface, ABI). Vendors make their
> tools conform - or they don't get to play in Windows market.

Now this is basically the complete answer. Anything else is just
"decoration" :-)!

> > Now, if this would require a
> > static import library, I would understand that this contains the
> > interface to the DLL to match the language to the internal style of
> > the DLL.
>
> I'm not sure what you mean by "internal style" of a DLL. I'm not
> familiar with the term.

I was proposing the fact, that inside the DLL could be any type of
coding unknown to it's exterior, IF the import-library would translate
that specific coding to some common interface for the outside world.
However, I noticed this idea had a flaw, since it doesn't explain
dynamic linking of DLLs.
Anyway, it didn't correspond to reality.

Thanks again,
regards,
Pelle.