View source for Name mangling

{{Short description|Technique in compiler construction}}
{{About|name mangling in computer languages|name mangling in file systems|filename mangling|other uses|Name conflict (disambiguation){{!}}Name conflict}}
{{Multiple issues|{{original research|date=September 2016}}{{More citations needed|date=December 2011}}}}

In [[compiler]] construction, '''name mangling''' (also called '''name decoration''') is a technique used to solve various problems caused by the need to resolve unique names for programming entities in many modern [[programming language]]s.

It provides means to encode added information in the name of a [[Function (computer programming)|function]], [[Record (computer science)|structure]], [[Class (programming)|class]] or another [[data type]], to pass more semantic information from the [[compiler]] to the [[Linker (computing)|linker]].

The need for name mangling arises where a language allows different entities to be named with the same [[identifier]] as long as they occupy a different [[namespace]] (typically defined by a module, class, or explicit ''namespace'' directive) or have different [[type signature]]s (such as in [[function overloading]]). It is required in these uses because each signature might require different, specialized [[calling convention]] in the [[machine code]].

Any [[object code]] produced by compilers is usually linked with other pieces of object code (produced by the same or another compiler) by a type of program called a [[Linker (computing)|linker]]. The linker needs a great deal of information on each program entity. For example, to correctly link a function it needs its name, the number of [[Argument of a function|arguments]] and their types, and so on.

The simple programming languages of the 1970s, like [[C (programming language)|C]], only distinguished [[subroutine]]s by their name, ignoring other information including [[Parameter (computer programming)|parameter]] and return types.
Later languages, like [[C++]], defined stricter requirements for routines to be considered "equal", such as the parameter types, return type, and calling convention of a function. These requirements enable method overloading and detection of some bugs (such as using different definitions of a function when compiling different [[source code]] files).
These stricter requirements needed to work with extant [[programming tool]]s and conventions. Thus, added requirements were encoded in the name of the symbol, since that was the only information a traditional linker had about a symbol.

== Examples ==
{{how-to|section|date=September 2016}}

=== C ===
Although name mangling is not generally required or used by languages that do not support [[function overloading]], like [[C (programming language)|C]] and classic [[Pascal (programming language)|Pascal]], they use it in some cases to provide added information about a function.
For example, compilers targeted at [[Microsoft Windows]] platforms support a variety of [[calling convention]]s, which determine the manner in which parameters are sent to subroutines and results are returned. Because the different calling conventions are incompatible with one another, compilers mangle symbols with codes detailing which convention should be used to call the specific routine.

The mangling scheme for Windows was established by Microsoft and has been informally followed by other compilers including [[Digital Mars]], [[Borland]], and [[GNU Compiler Collection]] (GCC) when compiling code for the Windows platforms. The scheme even applies to other languages, such as [[Pascal (programming language)|Pascal]], [[D (programming language)|D]], [[Delphi (software)|Delphi]], [[Fortran]], and [[C Sharp (programming language)|C#]]. This allows subroutines written in those languages to call, or be called by, extant Windows [[Library (computing)|libraries]] using a calling convention different from their default.

When compiling the following C examples:
<syntaxhighlight lang="c">
int _cdecl f(int x) { 
    return 0; 
}

int _stdcall g(int y) { 
    return 0; 
}

int _fastcall h(int z) { 
    return 0; 
}
</syntaxhighlight>

32-bit compilers emit, respectively:

 _f
 _g@4
 @h@4

In the {{code|stdcall}} and {{code|fastcall}} mangling schemes, the function is encoded as <code>_{{var|name}}@{{var|X}}</code> and <code>@{{var|name}}@{{var|X}}</code> respectively, where {{var|X}} is the number of bytes, in decimal, of the argument(s) in the parameter list (including those passed in registers, for fastcall). In the case of {{code|cdecl}}, the function name is merely prefixed by an underscore.

The 64-bit convention on Windows (Microsoft C) has no leading underscore. This difference may in some rare cases lead to unresolved externals when porting such code to 64 bits. For example, Fortran code can use 'alias' to link against a C method by name as follows:

<syntaxhighlight lang="fortran">
SUBROUTINE f()
!DEC$ ATTRIBUTES C, ALIAS:'_f' :: f
END SUBROUTINE
</syntaxhighlight>

This will compile and link fine under 32 bits, but generate an unresolved external <code>_f</code> under 64 bits. One workaround for this is not to use 'alias' at all (in which the method names typically need to be capitalized in C and Fortran). Another is to use the BIND option:

<syntaxhighlight lang="fortran">
SUBROUTINE f() BIND(C,NAME="f")
END SUBROUTINE
</syntaxhighlight>
<!--
*''todo: More stuff about parameter sizes and show mangling for different parameter lists, maybe variadics too.''
*''todo: Try the above with 16-bit compilers: I think those "4"s will become "2"s.''
*''todo: Try _pascal, _safecall, and FAR in 16-bit compilers too.''
-->

In C, most compilers also mangle static functions and variables (and in C++ functions and variables declared static or put in the anonymous namespace) in translation units using the same mangling rules as for their non-static versions. If functions with the same name (and parameters for C++) are also defined and used in different translation units, it will also mangle to the same name, potentially leading to a clash. However, they will not be equivalent if they are called in their respective translation units. Compilers are usually free to emit arbitrary mangling for these functions, because it is illegal to access these from other translation units directly, so they will never need linking between different object code (linking of them is never needed). To prevent linking conflicts, compilers will use standard mangling, but will use so-called 'local' symbols. When linking many such translation units there might be multiple definitions of a function with the same name, but resulting code will only call one or another depending on which translation unit it came from. This is usually done using the [[Relocation (computing)|relocation]] mechanism.

=== C++ ===
{{anchor|Name mangling in C++}}
[[C++]] compilers are the most widespread users of name mangling. The first C++ compilers were implemented as translators to [[C (programming language)|C]] source code, which would then be compiled by a C compiler to object code; because of this, symbol names had to conform to C identifier rules. Even later, with the emergence of compilers that produced machine code or assembly directly, the system's [[Linker (computing)|linker]] generally did not support C++ symbols, and mangling was still required.

The [[C++]] language does not define a standard decoration scheme, so each compiler uses its own. C++ also has complex language features, such as [[C++ class|classes]], [[C++ template|templates]], [[Namespace (C++)|namespaces]], and [[operator overloading]], that alter the meaning of specific symbols based on context or usage. Meta-data about these features can be disambiguated by mangling (decorating) the name of a [[symbol (computing)|symbol]]. Because the name-mangling systems for such features are not standardized across compilers, few linkers can link object code that was produced by different compilers.

====Simple example====
A single C++ translation unit might define two functions named {{code|f()}}:

<syntaxhighlight lang="cpp">
int f() { 
    return 1; 
}

int f(int) { 
    return 0; 
}

void g() { 
    int i = f();
    int j = f(0); 
}
</syntaxhighlight>

These are distinct functions, with no relation to each other apart from the name. The C++ compiler will therefore encode the type information in the symbol name, the result being something resembling:

<syntaxhighlight lang="cpp">
int __f_v() { 
    return 1; 
}

int __f_i(int) { 
    return 0; 
}
 
void __g_v() { 
    int i = __f_v();
    int j = __f_i(0); 
}
</syntaxhighlight>

Even though its name is unique, {{code|g()}} is still mangled: name mangling applies to ''all'' C++ symbols (except for those in an <syntaxhighlight lang="cpp" inline>extern "C"</syntaxhighlight> block).

====Complex example====
The mangled symbols in this example, in the comments below the respective identifier name, are those produced by the GNU GCC 3.x compilers, according to the [[IA-64]] (Itanium) ABI:

<syntaxhighlight lang="cpp">
export namespace wikipedia {

class Article {
public:
    std::string format();  // = _ZN9wikipedia7Article6formatEv

    bool printTo(std::ostream& os); // = _ZN9wikipedia7article8printToERSo

    class Wikilink {
    public:
        Wikilink(std::string_view name);  // = _ZN9wikipedia7Article8WikilinkC1ERKSs
    };
};

}
</syntaxhighlight>

All mangled symbols begin with {{code|_Z}} (note that an identifier beginning with an underscore followed by a capital letter is a [[reserved identifier]] in C, so conflict with user identifiers is avoided); for nested names (including both namespaces and classes), this is followed by {{code|N}}, then a series of &lt;length, id&gt; pairs (the length being the length of the next identifier), and finally {{code|E}}. For example, {{code|wikipedia::Article::format()}} becomes:

 _ZN9wikipedia7Article6formatE

For functions, this is then followed by the type information; as {{code|format()}} is a {{code|void}} function, this is simply {{code|v}}; hence:

 _ZN9wikipedia7Article6formatEv

For {{code|wikipedia::Article::printTo()}}, the standard type {{code|std::ostream}} (which is a {{mono|[[typedef]]}} for {{code|std::basic_ostream<char, std::char_traits<char>>}}) is used, which has the special alias {{code|So}}; a reference to this type is therefore {{code|RSo}}, with the complete name for the function being:

 _ZN9wikipedia7Article8printToERSo

====How different compilers mangle the same functions====
There isn't a standardized scheme by which even trivial C++ identifiers are mangled, and consequently different compilers (or even different versions of the same compiler, or the same compiler on different platforms) mangle public symbols in radically different (and thus totally incompatible) ways. Consider how different C++ compilers mangle the same functions:

{| class="wikitable"
 !Compiler
 !{{codett|void h(int)}}
 !{{codett|void h(int, char)}}
 !{{codett|void h(void)}}
 |-
 |Intel C++ 8.0 for Linux
 | rowspan=5 | {{codett|_Z1hi}}
 | rowspan=5 | {{codett|_Z1hic}}
 | rowspan=5 | {{codett|_Z1hv}}
 |-
 |HP aC++ A.05.55 [[IA-64]]
 |-
 |IAR EWARM C++
 |-
 |[[GNU Compiler Collection|GCC]] 3.''x'' and higher
 |-
 |[[Clang]]  1.''x'' and higher<ref>{{citation |url=http://clang.llvm.org/features.html#gcccompat |title=Clang - Features and Goals: GCC Compatibility |date=15 April 2013}}</ref>
 |-
 |[[GNU Compiler Collection|GCC]] 2.9.''x''
 | rowspan=2 | {{codett|h__Fi}}
 | rowspan=2 | {{codett|h__Fic}}
 | rowspan=2 | {{codett|h__Fv}}
 |-
 |HP aC++ A.03.45 PA-RISC
 |-
 |[[Microsoft Visual C++]] v6-v10 ([[v:Visual C++ name mangling|mangling details]])
 | rowspan=2 | {{codett|?h@@YAXH@Z}}
 | rowspan=2 | {{codett|?h@@YAXHD@Z}}
 | rowspan=2 | {{codett|?h@@YAXXZ}}
 |-
 |[[Digital Mars]] C++
 |-
 |[[Borland]] C++ v3.1
 |{{codett|@h$qi}}
 |{{codett|@h$qizc}}
 |{{codett|@h$qv}}
 |-
 |[[OpenVMS]] C++ v6.5 (ARM mode)
 |{{codett|H__XI}}
 |{{codett|H__XIC}}
 |{{codett|H__XV}}
 |-
 |OpenVMS C++ v6.5 (ANSI mode)
 |
 |{{codett|CXX$__7H__FIC26CDH77}}
 |{{codett|CXX$__7H__FV2CB06E8}}
 |-
 |OpenVMS C++ X7.1 IA-64
 |{{codett|CXX$_Z1HI2DSQ26A}}
 |{{codett|CXX$_Z1HIC2NP3LI4}}
 |{{codett|CXX$_Z1HV0BCA19V}}
 |-
 |SunPro CC
 |{{codett|__1cBh6Fi_v_}}
 |{{codett|__1cBh6Fic_v_}}
 |{{codett|__1cBh6F_v_}}
 |-
 |Tru64 C++ v6.5 (ARM mode)
 |{{codett|h__Xi}}
 |{{codett|h__Xic}}
 |{{codett|h__Xv}}
 |-
 |Tru64 C++ v6.5 (ANSI mode)
 |{{codett|__7h__Fi}}
 |{{codett|__7h__Fic}}
 |{{codett|__7h__Fv}}
 |-
 |Watcom C++ 10.6
 |{{codett|W?h$n(i)v}}
 |{{codett|W?h$n(ia)v}}
 |{{codett|W?h$n()v}}
 |}
Notes:
*The [[Compaq]] C++ compiler on [[OpenVMS]] [[VAX]] and [[DEC Alpha|Alpha]] (but not IA-64) and [[Tru64 UNIX]] has two name mangling schemes. The original, pre-standard scheme is known as the ARM model, and is based on the name mangling described in the C++ Annotated Reference Manual (ARM). With the advent of new features in standard C++, particularly [[template (programming)|templates]], the ARM scheme became more and more unsuitable – it could not encode certain function types, or produced identically mangled names for different functions. It was therefore replaced by the newer ''[[American National Standards Institute]]'' (ANSI) model, which supported all ANSI template features, but was not backward compatible.
*On IA-64, a standard [[application binary interface]] (ABI) exists (see [[#External links|external links]]), which defines (among other things) a standard name-mangling scheme, and which is used by all the IA-64 compilers. GNU GCC 3.''x'' has further adopted the name mangling scheme defined in this standard for use on other, non-Intel platforms.
*The [[Visual Studio]] and Windows SDK include the program {{code|undname}} which prints the C-style function prototype for a given mangled name.
*On Microsoft Windows, the Intel compiler<ref>{{cite web|url=https://community.intel.com/t5/Intel-C-Compiler/OBJ-differences-between-Intel-Compiler-and-VC-Compiler/td-p/871131|title=OBJ differences between Intel Compiler and VC Compiler|website=software.intel.com|archive-url=https://web.archive.org/web/20220520203123/https://community.intel.com/t5/Intel-C-Compiler/OBJ-differences-between-Intel-Compiler-and-VC-Compiler/td-p/871131|archive-date=2022-05-20|url-status=dead}}</ref> and [[Clang]]<ref>{{cite web|url=http://clang.llvm.org/docs/MSVCCompatibility.html#abi-features|title=MSVC compatibility|access-date=13 May 2016}}</ref> uses the Visual C++ name mangling for compatibility.

====Handling of C symbols when linking from C++====
The job of the common C++ idiom:

<syntaxhighlight lang="cpp">
#ifdef __cplusplus 
extern "C" {
#endif

// symbols here

#ifdef __cplusplus
}
#endif
</syntaxhighlight>

is to ensure that the symbols within are "unmangled" – that the compiler emits a binary file with their names undecorated, as a C compiler would do. As C language definitions are unmangled, the C++ compiler needs to avoid mangling references to these identifiers.

For example, the standard strings library, {{code|<string.h>}}, usually contains something resembling:

<syntaxhighlight lang="cpp">
#ifdef __cplusplus
extern "C" {
#endif

void* memset (void*, int, size_t);
char* strcat (char*, const char*);
int strcmp (const char*, const char*);
char* strcpy (char*, const char*);

#ifdef __cplusplus
}
#endif
</syntaxhighlight>

Thus, code such as:

<syntaxhighlight lang="cpp">
if (strcmp(argv[1], "-x") == 0) {
    strcpy(a, argv[2]);
} else {
    memset(a, 0, sizeof(a));
}
</syntaxhighlight>

uses the correct, unmangled {{code|strcmp}} and {{code|memset}}. If the {{code|extern "C"}} had not been used, the (SunPro) C++ compiler would produce code equivalent to:

<syntaxhighlight lang="cpp">
if (__1cGstrcmp6Fpkc1_i_(argv[1], "-x") == 0) {
    __1cGstrcpy6Fpcpkc_0_(a, argv[2]);
} else {
    __1cGmemset6FpviI_0_(a, 0, sizeof(a));
}
</syntaxhighlight>

Since those symbols do not exist in the C runtime library (''e.g.'' libc), link errors would result.

<!--
Useful links. I don't know which should end up in the finished article:
* http://www.ucmb.ulb.ac.be/documents/libg++_2.7.1/g++FAQ_35.html
* http://theoryx5.uwinnipeg.ca/gnu/gcc/gxxint_15.html    This one is ancient, should not be used.
* http://www.kegel.com/mangle.html   This one describes an old version of Visual C++.
* http://www.pgroup.com/ppro_docs/pgiws_ug/pgiug_14.htm
-->

====Standardized name mangling in C++====
It would seem that standardized name mangling in the C++ language would lead to greater interoperability between compiler implementations. However, such a standardization by itself would not suffice to guarantee C++ compiler interoperability and it might even create a false impression that interoperability is possible and safe when it isn't. Name mangling is only one of several [[application binary interface]] (ABI) details that need to be decided and observed by a C++ implementation. Other ABI aspects like [[exception handling]], [[virtual table]] layout, structure, and stack frame [[Data structure alignment|padding]] also cause differing C++ implementations to be incompatible. Further, requiring a particular form of mangling would cause issues for systems where implementation limits (e.g., length of symbols) dictate a particular mangling scheme. A standardized ''requirement'' for name mangling would also prevent an implementation where mangling was not required at all – for example, a linker that understood the C++ language.

The [[ISO/IEC 14882|C++ standard]] therefore does not attempt to standardize name mangling. On the contrary, the ''Annotated C++ Reference Manual'' (also known as ''ARM'', {{ISBN|0-201-51459-1}}, section 7.2.1c) actively encourages the use of different mangling schemes to prevent linking when other aspects of the ABI are incompatible.

Nevertheless, as detailed in the section above, on some platforms<ref>{{cite web|url=https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling|title=Itanium C++ ABI, Section 5.1 External Names (a.k.a. Mangling)|access-date=16 May 2016}}</ref> the full C++ ABI has been standardized, including name mangling.

====Real-world effects of C++ name mangling====
Because C++ symbols are routinely exported from [[Dynamic-link library|DLL]] and [[shared object]] files, the name mangling scheme is not merely a compiler-internal matter. Different compilers (or different versions of the same compiler, in many cases) produce such binaries under different name decoration schemes, meaning that symbols are frequently unresolved if the compilers used to create the library and the program using it employed different schemes. For example, if a system with multiple C++ compilers installed (e.g., GNU GCC and the OS vendor's compiler) wished to install the [[Boost C++ Libraries]], it would have to be compiled multiple times (once for GCC and once for the vendor compiler).

It is good for safety purposes that compilers producing incompatible object codes (codes based on different ABIs, regarding e.g., classes and exceptions) use different name mangling schemes. This guarantees that these incompatibilities are detected at the linking phase, not when executing the software (which could lead to obscure bugs and serious stability issues).

For this reason, name decoration is an important aspect of any C++-related [[Application binary interface|ABI]].

There are instances, particularly in large, complex code bases, where it can be difficult or impractical to map the mangled name emitted within a linker error message back to the particular corresponding token/variable-name in the source. This problem can make identifying the relevant source file(s) very difficult for build or test engineers even if only one compiler and linker are in use. Demanglers (including those within the linker error reporting mechanisms) sometimes help but the mangling mechanism itself may discard critical disambiguating information.

====Demangle via c++filt====
<syntaxhighlight lang="console">
$ c++filt -n _ZNK3MapI10StringName3RefI8GDScriptE10ComparatorIS0_E16DefaultAllocatorE3hasERKS0_
Map<StringName, Ref<GDScript>, Comparator<StringName>, DefaultAllocator>::has(StringName const&) const
</syntaxhighlight>

====Demangle via builtin GCC ABI====
<syntaxhighlight lang="cpp">
#include <cxxabi.h>

import std;

int main(int argc, char* argv[]) {
	const char* mangledName = "_ZNK3MapI10StringName3RefI8GDScriptE10ComparatorIS0_E16DefaultAllocatorE3hasERKS0_";
	int status = -1;
	char* demangledName = abi::__cxa_demangle(mangledName, nullptr, nullptr, &status);
	std::println("Demangled: {}", demangledName);
	std::free(demangledName);
	return 0;
}
</syntaxhighlight>

Output: 
 {{codett|Demangled: Map<StringName, Ref<GDScript>, Comparator<StringName>, DefaultAllocator>::has(StringName&) const}}

=== Java ===
In [[Java (programming language)|Java]], the ''signature'' of a method or a class contains its name and the types of its method arguments and return value, where applicable. The format of signatures is documented, as the language, compiler, and .class file format were all designed together (and had object-orientation and universal interoperability in mind from the start).

====Creating unique names for inner and anonymous classes====
The scope of anonymous classes is confined to their parent class, so the compiler must produce a "qualified" public name for the [[inner class]], to avoid conflict where other classes with the same name (inner or not) exist in the same namespace. Similarly, anonymous classes must have "fake" public names generated for them (as the concept of anonymous classes only exists in the compiler, not the runtime). So, compiling the following Java program:

<syntaxhighlight lang="java">
public class Foo {
    class Bar {
        public int x;
    }

    public void baz() {
        Object f = new Object() {
            public String toString() {
                return "hello";
            }
        };
    }
}
</syntaxhighlight>

will produce three '''.class''' files:
* '''foo.class''', containing the main (outer) class ''foo''
* '''foo$bar.class''', containing the named inner class ''foo.bar''
* '''foo$1.class''', containing the anonymous inner class (local to method ''foo.baz'')

All of these class names are valid (as {{mono|$}} symbols are permitted in the JVM specification) and these names are "safe" for the compiler to generate, as the Java language definition advises not to use {{mono|$}} symbols in normal java class definitions.

Name resolution in Java is further complicated at runtime, as [[fully qualified name]]s for classes are unique only inside a specific [[classloader]] instance. Classloaders are ordered hierarchically and each Thread in the JVM has a so-called context class loader, so in cases where two different classloader instances contain classes with the same name, the system first tries to load the class using the root (or system) classloader and then goes down the hierarchy to the context class loader.

====Java Native Interface====
[[Java Native Interface]], Java's native method support, allows Java language programs to call out to programs written in another language (usually C or C++). There are two name-resolution concerns here, neither of which is implemented in a [[Technical standard|standardized]] manner:

* JVM to native name translation - this seems to be more stable, since Oracle makes its scheme public.<ref>{{cite web |title=Design Overview |url=https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html |website=docs.oracle.com}}</ref>
* Normal C++ name mangling - see above.

=== Python ===
In [[Python (programming language)|Python]], mangling is used for class attributes that one does not want subclasses to use<ref>{{Cite web|url=https://www.python.org/dev/peps/pep-0008/#designing-for-inheritance|title = PEP 8 -- Style Guide for Python Code}}</ref> which are designated as such by giving them a name with two or more leading underscores and no more than one trailing underscore. For example, {{code|__thing}} will be mangled, as will {{code|___thing}} and {{code|__thing_}}, but {{code|__thing__}} and {{code|__thing___}} will not. Python's runtime does not restrict access to such attributes, the mangling only prevents name collisions if a derived class defines an attribute with the same name.

On encountering name mangled attributes, Python transforms these names by prepending a single underscore and the name of the enclosing class, for example:

<syntaxhighlight lang="python">
class Test:
    def __mangled_name(self) -> None:
        pass

    def normal_name(self) -> None:
        pass

if __name == "__main__":
    t: Test = Test()
    print([attr for attr in dir(t) if "name" in attr])
    # prints: ['_Test__mangled_name', 'normal_name']
</syntaxhighlight>

=== Pascal ===

====Turbo Pascal, Delphi====
<!--
todo: Borland Pascal and Delphi, at least, are object-oriented and can call C DLLs, so they likely have this issue too.
-->
To avoid name mangling in Pascal, use:

<syntaxhighlight lang="pascal">
exports
  myFunc name 'myFunc',
  myProc name 'myProc';
</syntaxhighlight>

====Free Pascal====
[[Free Pascal]] supports [[function overloading|function]] and operator overloading, thus it also uses name mangling to support these features. On the other hand, Free Pascal is capable of calling symbols defined in external modules created with another language and exporting its own symbols to be called by another language. For further information, consult [http://www.freepascal.org/docs-html/prog/progse21.html Chapter 6.2] and [http://www.freepascal.org/docs-html/prog/progse27.html 7.1] of [http://www.freepascal.org/docs-html/prog/prog.html Free Pascal Programmer's Guide].

=== Fortran ===
Name mangling is also necessary in [[Fortran]] compilers, originally because the language is [[case insensitive]]. Further mangling requirements were imposed later in the evolution of the language because of the addition of [[Module (programming)|modules]] and other features in the Fortran 90 standard. The case mangling, especially, is a common issue that must be dealt with to call Fortran libraries, such as [[LAPACK]], from other languages, such as [[C (programming language)|C]].

Because of the case insensitivity, the name of a subroutine or function {{code|FOO}} must be converted to a standardized case and format by the compiler so that it will be linked in the same way regardless of case. Different compilers have implemented this in various ways, and no standardization has occurred. The [[IBM AIX|AIX]] and [[HP-UX]] Fortran compilers convert all identifiers to lower case {{code|foo}}, while the [[Cray]] and [[Unicos]] Fortran compilers converted identifiers to all upper case {{code|FOO}}. The [[GNU]] [[GNU Compiler Collection|g77]] compiler converts identifiers to lower case plus an underscore {{code|foo_}}, except that identifiers already containing an underscore {{code|FOO_BAR}} have two underscores appended {{code|foo_bar__}}, following a convention established by [[f2c]]. Many other compilers, including [[Silicon Graphics]]'s (SGI) [[IRIX]] compilers, [[GNU Fortran]], and [[Intel]]'s Fortran compiler (except on Microsoft Windows), convert all identifiers to lower case plus an underscore ({{code|foo_}} and {{code|foo_bar_}}, respectively). On Microsoft Windows, the Intel Fortran compiler defaults to uppercase without an underscore.<ref>{{cite web|title=Summary of Mixed-Language Issues|url=https://software.intel.com/en-us/node/525345|website=User and Reference Guide for the Intel Fortran Compiler 15.0|publisher=Intel Corporation|access-date=17 November 2014}}</ref>

Identifiers in Fortran 90 modules must be further mangled, because the same procedure name may occur in different modules. Since the Fortran 2003 Standard requires that module procedure names not conflict with other external symbols,<ref>{{Cite web|url=https://software.intel.com/en-us/node/510637|title = Documentation Library}}</ref> compilers tend to use the module name and the procedure name, with a distinct marker in between. For example:

<syntaxhighlight lang="fortran">
module m 
contains
   integer function five()
      five = 5
   end function five
end module m
</syntaxhighlight>

In this module, the name of the function will be mangled as {{code|__m_MOD_five}} (e.g., GNU Fortran), {{code|m_MP_five_}} (e.g., Intel's ifort), {{code|m.five_}} (e.g., Oracle's sun95), etc. Since Fortran does not allow overloading the name of a procedure, but uses [[Fortran 95 language features#Overloading and generic interfaces|generic interface blocks]] and generic type-bound procedures instead, the mangled names do not need to incorporate clues about the arguments.

The Fortran 2003 BIND option overrides any name mangling done by the compiler, as shown [[#C name decoration in Microsoft Windows|above]].

=== Rust ===
{{expand section|date=June 2014}}
Function names are mangled by default in [[Rust (programming language)|Rust]]. However, this can be disabled by the {{code|#[no_mangle]}} function attribute. This attribute can be used to export functions to C, C++, or [[Objective-C]].<ref>{{cite web|title=Foreign Function Interface # Calling Rust code from C|url=https://doc.rust-lang.org/book/ffi.html#calling-rust-code-from-c|website=Rust Manual|publisher=rust-lang.org|access-date=13 May 2016}}</ref> Further, along with the {{code|#[start]}} function attribute or the {{code|#![no_main]}} crate attribute, it allows the user to define a C-style entry point for the program.<ref>{{cite web|title=No stdlib|url=https://doc.rust-lang.org/book/no-stdlib.html|website=Rust Manual|publisher=rust-lang.org|access-date=13 May 2016}}</ref>

Rust has used many versions of symbol mangling schemes that can be selected at compile time with an {{code|-Z symbol-mangling-version}} option. The following manglers are defined:

* {{code|legacy}} A C++ style mangling based on the Itanium IA-64 C++ ABI. Symbols begin with {{code|_ZN}}, and filename hashes are used for disambiguation. Used since Rust 1.9.<ref>{{cite web|title=rust/src/librustc_codegen_utils/symbol_names/legacy.r.rs at 57e1da59cd0761330b4ea8d47b16340a78eeafa9 · rust-lang/rust · GitHub|website=[[GitHub]]|date=3 November 2021|url=https://github.com/rust-lang/rust/blob/57e1da59cd0761330b4ea8d47b16340a78eeafa9/src/librustc_codegen_utils/symbol_names/legacy.rs#L134}}</ref>
* {{code|v0}} An improved version of the legacy scheme, with changes for Rust. Symbols begin with {{code|_R}}. Polymorphism can be encoded. Functions don't have return types encoded (Rust does not have overloading). Unicode names use modified [[punycode]]. Compression (backreference) use byte-based addressing. Used since Rust 1.37.<ref>{{cite web|title=Rust Symbol Mangling|url=https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html|website=The Rust RFC Book}}</ref>

Examples are provided in the Rust {{code|symbol-names}} tests.<ref>{{cite web|title=Rust 1.42.0: src/test/ui/symbol-names|url=https://github.com/rust-lang/rust/tree/1.42.0/src/test/ui/symbol-names|website=Github|access-date=20 March 2020}}</ref>

=== Objective-C ===
Essentially two forms of method exist in [[Objective-C]], the class [[Static method|("static") method]], and the [[instance method]]. A method declaration in Objective-C is of the following form:

 + (''return-type'') ''name''<sub>0</sub>:''parameter''<sub>0</sub> ''name''<sub>1</sub>:''parameter''<sub>1</sub> ...
 – (''return-type'') ''name''<sub>0</sub>:''parameter''<sub>0</sub> ''name''<sub>1</sub>:''parameter''<sub>1</sub> ...

Class methods are signified by +, instance methods use -. A typical class method declaration may then look like:

<syntaxhighlight lang="objc">
+ (id) initWithX: (int) number andY: (int) number;
+ (id) new;
</syntaxhighlight>

With instance methods looking like this:

<syntaxhighlight lang="objc">
- (id) value;
- (id) setValue: (id) new_value;
</syntaxhighlight>

Each of these method declarations have a specific internal representation. When compiled, each method is named according to the following scheme for class methods:

 _c_''Class''_''name''<sub>0</sub>_''name''<sub>1</sub>_ ...

and this for instance methods:

 _i_''Class''_''name''<sub>0</sub>_''name''<sub>1</sub>_ ...

The colons in the Objective-C syntax are translated to underscores. So, the Objective-C class method {{code|2=objc|+ (id) initWithX: (int) number andY: (int) number;}}, if belonging to the {{code|Point}} class would translate as {{code|_c_Point_initWithX_andY_}}, and the instance method (belonging to the same class) {{code|2=objc|- (id) value;}} would translate to {{code|_i_Point_value}}.

Each of the methods of a class are labeled in this way. However, to look up a method that a class may respond to would be tedious if all methods are represented in this fashion. Each of the methods is assigned a unique symbol (such as an integer). Such a symbol is known as a ''selector''. In Objective-C, one can manage selectors directly – they have a specific type in Objective-C – {{code|SEL}}.

During compiling, a table is built that maps the textual representation, such as {{code|_i_Point_value}}, to selectors (which are given a type {{code|SEL}}). Managing selectors is more efficient than manipulating the text representation of a method. Note that a selector only matches a method's name, not the class it belongs to: different classes can have different implementations of a method with the same name. Because of this, implementations of a method are given a specific identifier too, these are known as implementation pointers, and are also given a type, {{code|IMP}}.

Message sends are encoded by the compiler as calls to the {{code|2=objc|id objc_msgSend (id receiver, SEL selector, ...)}} function, or one of its cousins, where {{code|receiver}} is the receiver of the message, and {{code|SEL}} determines the method to call. Each class has its own table that maps selectors to their implementations – the implementation pointer specifies where in memory the implementation of the method resides. There are separate tables for class and instance methods. Apart from being stored in the {{code|SEL}} to {{code|IMP}} lookup tables, the functions are essentially anonymous.

The {{code|SEL}} value for a selector does not vary between classes. This enables [[Polymorphism (computer science)|polymorphism]].

The Objective-C runtime maintains information about the argument and return types of methods. However, this information is not part of the name of the method, and can vary from class to class.

Since Objective-C does not support [[namespace (programming)|namespaces]], there is no need for the mangling of class names (that do appear as symbols in generated binaries).

=== Swift ===
[[Swift (programming language)|Swift]] keeps metadata about functions (and more) in the mangled symbols referring to them. This metadata includes the function's name, attributes, module name, parameter types, return type, and more. For example:

The mangled name for a method {{code|func calculate(x: int) -> int}} of a {{code|MyClass}} class in module {{code|test}} is {{code|_TFC4test7MyClass9calculatefS0_FT1xSi_Si}}, for 2014 Swift. The components and their meanings are as follows:<ref>{{cite web|url=https://mikeash.com/pyblog/friday-qa-2014-08-15-swift-name-mangling.html|title=mikeash.com: Friday Q&A 2014-08-15: Swift Name Mangling|website=mikeash.com}}</ref>

* {{code|_T}}: The prefix for all Swift symbols. Everything will start with this.
* {{code|F}}: Non-curried function.
* {{code|C}}: Function of a class, i.e. a method
* {{code|4test}}: Module name, prefixed with its length.
* {{code|7MyClass}}: Name of class the function belongs to, prefixed with its length.
* {{code|9calculate}}: Function name, prefixed with its length.
* {{code|f}}: The function attribute. In this case ‘f’, which means a normal function.
* {{code|S0}}: Designates the type of the first parameter (namely the class instance) as the first in the type stack (here {{code|MyClass}} is not nested and thus has index 0).
* {{code|_FT}}: This begins the type list for the parameter tuple of the function.
* {{code|1x}}: External name of first parameter of the function.
* {{code|Si}}: Indicates builtin Swift type Swift.Int for the first parameter.
* {{code|_Si}}: The return type: again Swift.Int.

Mangling for versions since Swift 4.0 is documented officially. It retains some similarity to Itanium.<ref>{{cite web|title=apple/swift: mangling.rst|url=https://github.com/apple/swift/blob/main/docs/ABI/Mangling.rst|website=GitHub|date=3 November 2021|language=en}}</ref>

== See also ==
* [[API|Application programming interface]] (API)
* [[Application binary interface]] (ABI)
* [[Calling convention]]
* [[Comparison of application virtualization software]] (i.e. VMs)
* [[Foreign function interface]] (FFI)
* [[Java Native Interface]] (JNI)
* [[Language binding]]
* [[Stropping (syntax)|Stropping]]
* [[SWIG]]

==References==
{{reflist}}

==External links==
* [https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling Linux Itanium ABI for C++], including name mangling scheme.
* [https://developer.apple.com/tools/mpw-tools/compilers/docs/abi_spec.pdf Macintosh C/C++ ABI Standard Specification]
* [https://sourceware.org/binutils/docs/binutils/c_002b_002bfilt.html c++filt] – filter to demangle encoded C++ symbols for GNU/Intel compilers
* [http://msdn2.microsoft.com/en-us/library/5x49w699.aspx undname] – msvc tool to demangle names.
* [http://demangler.com demangler.com] – An online tool for demangling GCC and MSVC C++ symbols
* [https://developer.apple.com/legacy/mac/library/documentation/Cocoa/Conceptual/OOPandObjC1/Articles/ocRuntimeSystem.html#//apple_ref/doc/uid/TP40005191-CH9-CJBBBCHG The Objective-C Runtime System] – From Apple's ''[https://developer.apple.com/legacy/mac/library/documentation/Cocoa/Conceptual/OOPandObjC1/Introduction/introObjectiveC.html The Objective-C Programming Language 1.0]''
* [http://www.agner.org/optimize/calling_conventions.pdf Calling conventions for different C++ compilers] by [[Agner Fog]] contains detailed description of name mangling schemes for various x86 and x64 C++ compilers (pp.&nbsp;24–42 in 2011-06-08 version)
* [http://www.kegel.com/mangle.html#operators C++ Name Mangling/Demangling] Quite detailed explanation of Visual C++ compiler name mangling scheme
* [https://sourceforge.net/projects/php-ms-demangle/ PHP UnDecorateSymbolName] a php script that demangles Microsoft Visual C's function names.
* [https://web.archive.org/web/20140410114817/http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html Mixing C and C++ Code]
* {{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |chapter=Chapter 5: Symbol management |chapter-url=https://archive.today/20130126113557/http://www.iecc.com/linker/linker05.html<!-- http://www.iecc.com/linker/linker05.html --> |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}} Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]
* [http://www.int0x80.gr/papers/name_mangling.pdf Name mangling demystified by Fivos Kefallonitis]

{{Application binary interface}}

[[Category:C++]]
[[Category:Computer libraries]]
[[Category:Java (programming language)]]
[[Category:Compiler construction]]
[[Category:Articles with example Java code]]
[[Category:Articles with example Python (programming language) code]]
[[Category:Articles with example C++ code]]
[[Category:Articles with example C code]]