Editing Name mangling (section)

=== 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.