Talk:Name mangling

Wrong statement about Java

The statement “All of these class names are valid (as $ symbols are permitted in the JVM specification) and these names are "safe" for the compiler to generate, as the Java language definition prohibits $ symbols in normal java class definitions.” is completely wrong.

The character '$' is a legal character for Java identifiers, including class names. It is a rather discouraged character so it makes clashes between compiler-generated and user-defined class names unlikely but, in fact, there is nothing preventing collisions between these names. 77.12.74.48 (talk) —Preceding undated comment added 14:05, 22 January 2014 (UTC)

That’s right. The following code is legal Java but will cause errors due to the naming conflicts:

public class foo {
    class bar { }
}
class foo$bar {}

Renaming foo$bar to foo$baz will make it legal code which can be compiled without errors.

77.3.48.74 (talk) — Preceding undated comment added 08:59, 28 May 2015 (UTC)

Need for Name Mangling

The page introduction suggests that name mangling (euphemistically called "decoration") is needed in a particular case. I know what this is getting at, but suggest that this is not strictly true, that not all cases are covered, and that the causes of the use of name mangling should be more precisely drawn out by considering the intermediate form (e.g. object code) and its consumers (e.g. linkers), and their limitations, which require name mangling to be used, though I can't say this succinctly, so here are my ramblings...

The page says "The need [for name mangling] arises where the language allows different entities to be named with the same identifier as long as they occupy a different namespace (where a namespace is typically defined by a module, class, or explicit namespace directive)."

Firstly, when the same-named entities are in different namespaces then an entity can be unambiguously identified by its fully qualified name (e.g. namespace0.namespace1...class0.class1...identifier). Strictly, in this case, name mangling would be _needed_ only if there were no other means of representing in some intermediate form (e.g. object code) the fully qualified name, along with the number and types of function/method arguments, and other information (e.g. static/non-static, public/protected/private). A limitation of the intermediate form to fully represent the required information, and/or a limitation of the implementation of consumers (e.g. linkers) of an intermediate form, might impose a requirement for name mangling, but name mangling is not strictly _needed_ if the intermediate form has a means of representing all the required information and the consumers are implemented to use that information. The section on name-mangling not being generally required (with some exceptions) in Java makes this point by saying Java was designed with object-orientation in mind.

Secondly, the definition does not include the case where the same-named entities are in the _same_ namespace, which happens, for example, when a function/method identifier is overloaded within a class definition. Some disambiguation rules (e.g. considering the number and type of function/method arguments) are employed to identify the entity being refered to. A suitably rich intermediate form and employment of disambiguation rules means that name mangling is not strictly _needed_ in this case. — Preceding unsigned comment added by 77.100.246.52 (talk) 11:18, 8 June 2012 (UTC)

int not void?

The C++ seems to be wrong - those are void functions returning ints. I figured you meant their return types to be int? -- Finlay McWalter | Talk 21:18, 15 Jun 2004 (UTC)

Oops. They were int originally and I changed them halfway through. — Lady Lysine Ikinsile 21:22, Jun 15, 2004 (UTC)

Oh, and the "mangled name" table is wrong too - the examples are f, f, g, but the table is f, f, f -- Finlay McWalter | Talk 21:20, 15 Jun 2004 (UTC)

They aren't intended to correspond to the previous example. — Lady Lysine Ikinsile 21:22, Jun 15, 2004 (UTC)

Yep - I was confused because there were three of each, and f() was used - I realise we'll need quite a number of the latter kind, and maybe we should rename them h() or something, just to make sure? -- Finlay McWalter | Talk 21:29, 15 Jun 2004 (UTC)

version numbers

I think we should say which version of each compiler we're using. I think GCC changed from one scheme to another when they changed from the old codebase to the EGCS version. (I get the results you do with gcc v3.3.1). -- Finlay McWalter | Talk 22:09, 15 Jun 2004 (UTC)

Yes, they did change at some point — I think with gcc 3.0, but it may have been 3.1 (?). I'm pretty certain 2.95 uses the old scheme. Pre-egcs (2.7? 2.8 was egcs, wasn't it, or was that 2.9x?) may have used something different still. The new scheme is some kind of standard, at least on Linux (and Intel ICC uses the same scheme on Linux) ... GCC also use the same scheme on Solaris (at least - that's all I have to test with here), even though it differs from Sun's native C++ compiler. Not sure whether GCC inspired the standard or the other way around. (Tested with: solaris 9, "gcc version 3.3.2" and "CC: Sun C++ 5.5 2003/03/12"; suse linux 9.1, "gcc version 3.3.3 (SuSE Linux)") — Lady Lysine Ikinsile 22:21, Jun 15, 2004 (UTC)

yeah, I think that 2.95 -> 3.0 is the transition (I seem to remember lots of things sticking on 2.95 for ages). This [1] says gcc's scheme "seems to be based on the one in the C++ Reference Manual" -- Finlay McWalter | Talk 22:44, 15 Jun 2004 (UTC)

These are the results from gcc 2.95:

h(int)       -> h__Fi
h(int, char) -> h__Fic
h(void)      -> h__Fv

not sure if it's worth putting those in as well as 3.x. — Lady Lysine Ikinsile 22:48, Jun 15, 2004 (UTC)

Yeah, I think that's good information. It shows that even different versions of the same compiler can produce different output, and thus compounds the DLL hell. -- Finlay McWalter | Talk 22:55, 15 Jun 2004 (UTC)

great progress

Wow, it's so much better already - thanks for your (disproportionately dilligent) contributions. I've dropped User:Alfio a note about name decoration, asking if he'd like to help. I think I'll temporarily recuse myself from the C++ section (as I'm nearing the limit of my lame C++ skills) and I'll go finish the java section (ah, at least java has a standard mangling scheme and a standard ABI). Btw, my MSVC6 compiler is too old to compile the larger example (surprisingly it likes "namespace" but chokes on "std::") - I think it's fine if we just cite one or two compilers for the larger example (the trivial case amply makes our point that things are totally different). Thanks again. -- Finlay McWalter | Talk 00:29, 16 Jun 2004 (UTC)

I think the larger example could be better: I was getting a headache from deciphering the ABI documentation [2] and wasn't really capable of producing wonderful prose at the same time :) I'll try to clean it up a little.

 

Yes, I think it's fine to only consider one compiler here: the general concept of mangling is the same between all of them.

 

The larger example should work on MSVC6 (with #include <string> and <iostream>), even if it is a horribly broken compiler. Incidentally, someone on IRC mentioned they'd add ObjC examples later :) I'll also install Intel C++ at some point to add that to the table ... what other compilers are missing? (Comeau comes to mind) — Lady Lysine Ikinsile 00:47, Jun 16, 2004 (UTC)

Silly me, didn't #include anything :) Compilers: does Cfront still exist? There's an SGI mips compiler (which was kick ass a decade ago, last time I touched MIPS). I hope the ObjC person has access to a different compiler than the gcc ObjC frontend - I do know that gcj (the java frontend to gcc) just uses the g++ mangling scheme (makes sense) so you'd think the gcc-objc frontend does too (and thus wouldn't be such an interesting example). I saw your edit on Alfio's page - duhh, I'd forgotten about decoration for calling convention. And it seems we don't have a page on calling conventions either (stdcall, fastcall, cdecl, pascal,...). -- Finlay McWalter | Talk 01:05, 16 Jun 2004 (UTC)

No, objc doesn't, there's a regular scheme to how method names are mangled in objc. However, I do think there are different ways of implementing selectors, I'll have to look around and get back to you on that. Dysprosia 05:49, 16 Jun 2004 (UTC)

IA64 ABI

"GNU GCC 3.x and all the IA-64 compilers use the same IA-64 ABI, which defines (among other things) a standard name-mangling scheme."

Is this ABI x86/IA64 only, or does it use the same ABI even on SPARC, PPC, etc.? -- Finlay McWalter | Talk 17:37, 16 Jun 2004 (UTC)

I'm not entirely sure. I've just tested GCC on Linux i386, Solaris 9 i386, HP-UX 11.11 PA-RISC, Linux Alpha, Tru64 5.1b Alpha, Linux SPARC (32-bit and 64-bit) and Linux AMD64 (64-bit), and it used identical mangling schemes on all of them (_Z1h etc). I don't know, though, if rest of the ABI is the same on those platforms. The standard itself is published as "Itanium ABI" (see the link in ==External links==). I should probably reword the paragraph to say that on IA-64 the entire ABI is standardised, and that GCC uses the IA-64 name mangling scheme (at least) on all other systems, too. — Lady Lysine Ikinsile 17:52, Jun 16, 2004 (UTC)

status?

At what point is this article going to move to the main namespace? I'd think a reasonable overview of C++ and Java is probably reasonable to start with, though I'm not sure how detailed 'reasonable' is :) — Lady Lysine Ikinsile 03:58, Jun 17, 2004 (UTC)

I am not sure where to raise this issue but what exactly meant in article by saying "languages not supporting function overloading such as C" AFAIK and AFAIDIMT (done it many times?) C supports function overloading.

Standard C does not support function overloading, and I've never seen a C compiler that supports it. Just so we're clear, if a C compiler supported function overloading, this code would compile, but every compiler that I'm aware of will complain about a multiple definition of f:

int f(int x) { return x; }
int f(int x, int y) { return x+y; }

Mnudelman (talk) 18:05, 12 November 2013 (UTC)

Mangling and Decoration

The article Name decoration should be merged with this article. This will help avoiding redundant information as well as confusion. The reader will be unable to guess which one is the latest and most updated. Secondly, both are actually the same things, it is pointless to have two pages for synonyms.

Agreed, but arguably the "proper" name is "decoration" so it should be merged the other way. With a redirect left behind, it doesn't really matter though. Eric 04:38, 10 January 2006 (UTC)

Ok, I've finished merging that article into this one. -- Bovineone 05:52, 10 March 2006 (UTC)

Type-Casting of Function Argument In Cross Library Function Calls

Can the below explained be a name mangling problem??

Today, I faced a strange ‘C’ problem that had forced me to go through the C fundamentals again.

STRANGE PROBLEM:Consider you are working in for LIB_A and calling some foo function of LIB_B

LIB_A

void xyz()

{ unsigned short usVar = 12; /* Call function foo from LIB_B */ foo(usVar); …….. }

LIB_B

void foo(unsigned int uiVar) { /* guess what should be the value of uiVar when called from xyz */ }

I found that the value of uiVar = 0x0038000C(Hex).

After analyzing to the value above 0011 1000 0000 0000 0000 1100 (0x0038000C) with the correct value 0000 0000 0000 0000 0000 1100 (0x0000000C)

I was pretty sure in a way that this is to do with type-casting. When I change function xyz with explicit cast

void xyz() { unsigned short usVar = 12; /* Call function foo*/ foo( (unsigned int ) usVar); …….. }

I got the right value. But why it would need an explicit cast? According to general C typecast or coercion or automatic conversion concept, unsigned short should automatically be converted into unsigned int (without explicit cast).

Isn’t it??

NOTE: LIB_A and LIB_B played an important role here because in the same library it works as it should.

I was struggling for an answer and then I tried playing with MSVC settings, I found an option “RTTI” Run Time Type Information under VC++->Project Settings->C\C++(Tab)->Categrory = C++ Language(Enable Run-Time Type Information (RTTI)

Strangely when I enabled this, I started getting the correct values.

Then I relied on the following two links to conclude that we should enable RTTI option in all our libraries to avoid such kinds of error.

http://www.duckware.com/bugfreec/chapter7.html#avoidtypecasts

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vccelng4/html/elgrfRundshTimeTypeInformation.asp

I don't think Wikipedia is the proper site for this, but anyway...

I think your problem is not related with name mangling or RTTI (and both unrelated one another), but with automatic function prototyping, that is, if you use a function without a prototype (ie. foo) without a prototype, the compiler will guess the number and type of parameters from the actual parameters it gets (in your case a short).

But note that automatic function prototyping is a deprecated feature of C, and in C++ it is just not valid. Simply #include the appropiate .h files and all will be ok.

--Pinzo 00:19, 15 November 2006 (UTC)

Too technical?

Does this article strike anyone is being overly technical, especially with such a vague introduction? —The preceding unsigned comment was added by 68.252.72.221 (talk • contribs) .

I've added in more lead section text from the Name decoration article that I just merged into here. This article should be a little more accessible to a wider audience now. -- Bovineone 05:57, 10 March 2006 (UTC)

Cases of mangling in C++

AFAIK, default arguments don't affect name mangling, because they are not part of the function signature...

BTW, what is "variable ownership"???

--Pinzo 00:11, 15 November 2006 (UTC)

No name decorations in C for GNU gcc

Just a minor issue with the "C name decorations in Microsoft Windows" section.

The mangling scheme was established by Microsoft, and has been informally followed by other compilers including Digital Mars, Borland, and GNU gcc.

Actually, GNU gcc does not name-mangle C function declarations. Maybe we should rephrase this by removing GCC or move this to the C++ section. --Periophthalmus modestus 15:51, 26 July 2007 (UTC)

Oh yes it does. Try it. This example shows gcc-3.4.4 and gcc-4.3.2 on ((Cygwin)):

$ cat m.c
int _cdecl    f (int x) { return 0; }
int _stdcall  g (int y) { return 0; }
int _fastcall h (int z) { return 0; }

$ /bin/gcc-3 -c m.c -o m.o --save-temps

$ nm m.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000016 T @h@4
00000000 T _f
0000000a T _g@4

$ /bin/gcc-4 -c m.c -o m.o --save-temps

$ nm m.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000016 T @h@4
00000000 T _f
0000000a T _g@4

82.6.108.62 (talk) 22:23, 28 June 2009 (UTC)

Layout

Those middots in the examples are confusing. I know they're meant to clarify the syntax, but it took me a while to see what they stand for (nothing). Maybe rather use thin boxes or alternating backgrounds? —Preceding unsigned comment added by 87.162.46.92 (talk) 22:32, 21 August 2008 (UTC)

I agree, they are very confusing. I'm going to remove them. If the breakdown of the mangled name isn't obvious from the formatting (italics and bold) combined with the explanation, then further explanation should be given, but using middots in the name when they aren't part of the name is not a good solution. --Bigpeteb (talk) 15:31, 28 April 2014 (UTC)

Extern C

It should be possible to turn-off name mangling without using extern c? (e.g. to export a 'plain name' function from DLL which accepts C++ class as parameter) A .def file can do this in MSVC++, not sure if there are any other ways. 80.177.58.130 (talk) 12:06, 12 December 2008 (UTC)

Exporting symbols for use in DLLs should not be confused with name decoration. They are two separate issues. The actual names (internal symbols) are still decorated; using a DEF file (or one or two other methods) does not "turn off" decoration algorithms, but rather aliases the decorated symbol. In the final linking steps, the linker places the "alias" in the export table instead of the decorated name. (Recall that you do not, in fact, have to supply *any* name for an exported symbol, and can export only the ordinal to point to the appropriate address.) —Preceding unsigned comment added by 192.35.35.34 (talk) 21:35, 14 April 2010 (UTC)

Incompatibilities

Regarding incompatibilities between different compilers: Does this imply that for all Windows shared library to be accessible for all possible programs these shared libraries must all be compiled with the same compiler? --Abdull (talk) 17:15, 16 January 2010 (UTC)

Only if all of the relevant libraries are written in C++ - and then, it's just a matter of matching compiler ABI, for example, Digital Mars C++ is ABI-compatible with Visual C++. C, on the other hand, has a standard ABI and code should be able to use standard C calls to call code compiled by any compiler - sometimes even if the code being called is written in an entirely different language. Segin (talk) 07:24, 6 July 2010 (UTC)

Name mangling in Delphi

AFAIK, Delphi (tested: Borland Delphi 2006 for Win32) does not mangle names in DLL exports. The function myFunc stays "myFunc". There is no need to use "name 'myFunc'". AFAIK, Delphi and Lazarus are always creating undecorated names, that's why the undecorated style is called PASCAL-style ( Ref: http://support.microsoft.com/kb/140485/EN-US ) --80.139.126.193 (talk) 01:02, 2 September 2011 (UTC)

See the comment two section about DLL exports in general. — Preceding unsigned comment added by 86.104.57.160 (talk) 16:50, 18 December 2011 (UTC)

IBM compilers?

Someone should add info for those. I think they are mostly gcc-compatible on Z-stuff, but I don't know about Visual Age on Windows etc.

Do C++-only linkers exist?

In the "Standardised name mangling in C++" section, this article implies that they do, but doesn't give any examples, and I haven't heard of any. — Preceding unsigned comment added by 86.104.57.160 (talk) 17:52, 18 December 2011 (UTC)

External links modified (February 2018)

Hello fellow Wikipedians,

I have just modified one external link on Name mangling. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140410114817/http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html to http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:44, 11 February 2018 (UTC)

Is it wikipedia.naughty to use article links as section names?

A number of sections in this article concern particular programming languages.

I would regard it as improvement if at the top of, e.g. the Rust section, one could simply click thru to the language article.

The most "obvious" way would be for the section name itself to be an article link.

Example: "== C ==" becomes "== [ [C ] ] =="

[Pardon the extra spaces. Without them something is eating my square braces.]

Is there a wikipedia rule/guideline discouraging that practice? Has it been tried before and proven a disaster?

Alternatively at the beginning of each section the language might be mentioned, as a link.

Does anyone regard any of this as a "bad" idea? 2601:1C2:881:3630:B49F:BCD4:797C:7F32 (talk) 03:07, 11 September 2022 (UTC)

MOS:SECTIONS says "For technical reasons, section headings should: … Not contain links, especially where only part of a heading is linked." You could include hat templates for the section like TEMPLATE:Further or TEMPLATE:See also which might point to a particular section, e.g. C++#Compatibility. StrayBolt (talk) 18:24, 12 September 2022 (UTC)

Too detailed

I think all the details, are just too technical, implementation defined, and not worth being in encylopedia. Such details should stay in the respective programming languages and compiler documentations, not wikipedia.

Half of this article should be easily removed. 85.195.241.133 (talk) 03:36, 29 January 2023 (UTC)