The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Dave Bacher — Wed, 30 May 2012 19:48:07 GMT

@Joshua:

If you pop over to msdn.microsoft.com, and search on "Module Definition File," you'll find the format specs.

However, basically, you do this:

x=__x @1

x2=_x @2

x3=x @3

If you screw it up, the linker gives the usual suite of complaints -- General Protection Fault, Ambiguous Symbol, symbol not found, etc.

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

David Walker — Tue, 29 May 2012 14:53:40 GMT

Yes, I definitely understand the incorrect interpretation of the documentation. It's hard to write good documentation!

When I see something that says "if such and such is not desired, do this", I naturally assume that if I "do this", then "such and such" won't happen.

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

foo — Sun, 27 May 2012 10:27:42 GMT

@Yuriy: Ah right, so using extern "C" disabled C++ name mangling. Cool.

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Medinoc — Sat, 26 May 2012 19:58:12 GMT

I remember I failed a school project because I assumed prefixing C symbols with an underscore was universal after seeing on both DOS (QuickC) and Windows (Visual and MinGW). I learned at my expense that *n*x systems don't add anything.

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Anonymous Coward — Sat, 26 May 2012 13:45:09 GMT

I must say I initially also read the documentation as ‘extern "C" will disable name mangling’. Of course, when I tried to use the DLL I quickly discovered that this was not case. But I'm afraid it was easier to add ‘-Wl,--kill-at’ to the makefile than to have the added burden of a .def-file that must be kept in synch with the source files.

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Yuriy Gettya — Sat, 26 May 2012 12:54:37 GMT

@foo:

I've got a .dll compiled with /Gd (__cdecl), here's how a function is prototyped and declared:

extern "C" xENGINE_API HRESULT CreateInstance(shared_ptr<xFramework::IPlugin>& ppPlugin);

HRESULT CreateInstance(shared_ptr<xFramework::IPlugin>& ppPlugin)

----- results of dumpbin:

ordinal hint RVA name

1 0 00011398 CreateInstance = @ILT+915(_CreateInstance)

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

foo — Sat, 26 May 2012 06:00:53 GMT

@Yuriy. Maybe I'm missing something, but I don't see that using MSVC if I declare & define foo() as you suggest, except with __stdcall convention.

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Joshua — Fri, 25 May 2012 22:51:14 GMT

How does the linker figure it out at build time that the compiler exported symbol x@42 is the .def symbol x.

I'm not sure this can happen but if it did I'd imagine it would be worse:

__x

EXPORTS x

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

640k — Fri, 25 May 2012 17:41:07 GMT

Why is this even an issue 2012? The docs should have been super clear on this for the last 20 years.

[We thought the docs were clear on this, especially since nobody asked about it until 2011. -Raymond]

re: The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Steve Friedl — Fri, 25 May 2012 17:41:00 GMT

@Aaron - the C language itself doesn't provide for this, but an implementation might. Microsoft C compilers disambiguate the calling convention to avoid catastrophic stack corruption on mismatch.

Ref: unixwiz.net/.../win32-callconv.html