Deformación de nombres

Aunque la modificación de nombres no suele ser necesaria ni utilizada por lenguajes que no admiten sobrecarga de funciones , como C y Pascal clásico , en algunos casos la emplean para proporcionar información adicional sobre una función. Por ejemplo, los compiladores para plataformas Microsoft Windows admiten diversas convenciones de llamada , que determinan cómo se envían los parámetros a las subrutinas y cómo se devuelven los resultados. Dado que las distintas convenciones de llamada son incompatibles entre sí, los compiladores modifican los símbolos con códigos que detallan qué convención debe utilizarse para llamar a la rutina específica.

El esquema de codificación para Windows fue establecido por Microsoft y ha sido adoptado informalmente por otros compiladores, como Digital Mars , Borland y GNU Compiler Collection (GCC), al compilar código para plataformas Windows. Este esquema incluso se aplica a otros lenguajes, como Pascal , D , Delphi , Fortran y C# . Esto permite que las subrutinas escritas en dichos lenguajes llamen a bibliotecas de Windows existentes, o sean llamadas por ellas, utilizando una convención de llamada diferente a la predeterminada.

Al compilar los siguientes ejemplos en C:

int _cdecl f ( int x ) { return 0 ; }int _stdcall g ( int y ) { return 0 ; }int _fastcall h ( int z ) { return 0 ; }

Los compiladores de 32 bits emiten, respectivamente:

_F _g@4 @h@4

En los esquemas de manipulación stdcally fastcall, la función se codifica como y respectivamente, donde X es el número de bytes, en decimal, del/los argumento(s) en la lista de parámetros (incluidos los pasados ​​en registros, para fastcall). En el caso de , el nombre de la función simplemente se antepone con un guion bajo._name@X@name@Xcdecl

La convención de 64 bits en Windows (Microsoft C) no tiene guion bajo inicial. Esta diferencia puede, en algunos casos excepcionales, provocar que las variables externas no se resuelvan al portar dicho código a 64 bits. Por ejemplo, el código Fortran puede usar 'alias' para enlazar con un método C por su nombre, como se muestra a continuación:

SUBRUTINA f () !DEC$ ATRIBUTOS C, ALIAS:'_f' :: f FIN DE SUBRUTINA

Esto compilará y enlazará correctamente en 32 bits, pero generará un error externo no resuelto _fen 64 bits. Una solución alternativa es no usar 'alias' en absoluto (en el que los nombres de los métodos normalmente deben escribirse con mayúscula en C y Fortran). Otra es usar la BINDopción de Fortran 2003:

SUBRUTINA f () ENLAZAR ( C , NOMBRE = "f" ) FIN DE LA SUBRUTINA

En C, la mayoría de los compiladores también modifican las funciones y variables estáticas (y en C++ las funciones y variables declaradas como estáticas o ubicadas en el espacio de nombres anónimo) en las unidades de traducción, utilizando las mismas reglas de modificación que para sus versiones no estáticas. Si se definen y utilizan funciones con el mismo nombre (y parámetros para C++) en diferentes unidades de traducción, también se modificarán al mismo nombre, lo que podría provocar un conflicto. Sin embargo, no serán equivalentes si se llaman en sus respectivas unidades de traducción. Los compiladores suelen tener libertad para generar modificaciones arbitrarias para estas funciones, ya que es ilegal acceder a ellas directamente desde otras unidades de traducción, por lo que nunca necesitarán enlazarse entre diferentes códigos objeto (el enlace entre ellas nunca es necesario). Para evitar conflictos de enlace, los compiladores utilizarán la modificación estándar, pero usarán los llamados símbolos "locales". Al enlazar muchas de estas unidades de traducción, puede haber múltiples definiciones de una función con el mismo nombre, pero el código resultante solo llamará a una u otra dependiendo de la unidad de traducción de la que provenga. Esto generalmente se hace mediante el mecanismo de reubicación .

Los compiladores de C++ son los que más utilizan la modificación de nombres de símbolos (name mangling). Los primeros compiladores de C++ se implementaron como traductores de código fuente C , que luego era compilado por un compilador C a código objeto; por ello, los nombres de los símbolos debían ajustarse a las reglas de identificación de C. Incluso más tarde, con la aparición de compiladores que generaban directamente código máquina o ensamblador, el enlazador del sistema generalmente no admitía símbolos C++, y la modificación de nombres de símbolos seguía siendo necesaria.

El lenguaje C++ no define un esquema de decoración estándar, por lo que cada compilador utiliza el suyo propio. C++ también posee características de lenguaje complejas, como clases , plantillas , espacios de nombres y sobrecarga de operadores , que modifican el significado de símbolos específicos según el contexto o el uso. Los metadatos sobre estas características pueden desambiguarse modificando (decorando) el nombre de un símbolo . Dado que los sistemas de modificación de nombres para dichas características no están estandarizados entre compiladores, pocos enlazadores pueden enlazar código objeto generado por diferentes compiladores.

int f () { return 1 ; }int f ([[ maybe_unused ]] int x ) { return 0 ; }void g () { int i = f (); int j = f ( 0 ); }

int __f_v () { return 1 ; }int __f_i ([[ maybe_unused ]] int x ) { return 0 ; } void __g_v () { int i = __f_v (); int j = __f_i ( 0 ); }

exportar módulo wikipedia . estructura . Artículo ;importar std ;using std :: ostream ; using std :: string ; using std :: string_view ;exportar espacio de nombres wikipedia :: estructura {clase Artículo { público : artículo explícito ( nombre de la vista de cadena );~ Artículo () = predeterminado ;[[ nodiscard ]] formato de cadena (); // = _ZN9wikipedia8structure7Article6formatEvbool printTo ( ostream & os ); // = _ZN9wikipedia8structure7article6printToERSoclase Wikilink { public : explicit Wikilink ( string_view name ); // = _ZN9wikipedia8structure7Article6WikilinkC1ERKSs~ Wikilink () = predeterminado ; }; };}

_ZN9wikipedia8estructura7Artículo6formatoE

_ZN9wikipedia8estructura7Artículo6formatoEv

_ZN9wikipedia8estructura7Artículo6imprimirAERSo

#ifdef __cplusplus extern "C" { #endif// símbolos aquí#ifdef __cplusplus } #endif

#ifdef __cplusplus extern "C" { #endifvoid * memset ( void * s , int c , size_t n ); char * strcat ( char * s1 , const char * s2 ); int strcmp ( const char * s1 , const char * s2 ); char * strcpy ( char * s1 , const char * s2 );#ifdef __cplusplus } #endif

if ( strcmp ( argv [ 1 ], "-x" ) == 0 ) { strcpy ( a , argv [ 2 ]); } else { memset ( a , 0 , sizeof ( a )); }

if ( __1cGstrcmp6Fpkc1_i_ ( argv [ 1 ], "-x" ) == 0 ) { __1cGstrcpy6Fpcpkc_0_ ( a , argv [ 2 ]); } else { __1cGmemset6FpviI_0_ ( a , 0 , sizeof ( a )); }

$ c++filt -n _ZNK3MapI10StringName3RefI8GDScriptE10ComparatorIS0_E16DefaultAllocatorE3hasERKS0_ Map<StringName, Ref<GDScript>, Comparator<StringName>, DefaultAllocator>::has(StringName const&) const

importar < cxxabi . h > ;importar 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 ; }

Demangled: Map<StringName, Ref<GDScript>, Comparator<StringName>, DefaultAllocator>::has(StringName&) const

El lenguaje de programación C# evita por completo el uso de la modificación de nombres, confiando en cambio en los metadatos en la representación del Lenguaje Intermedio Común . Los símbolos C/C++ sin modificar (marcados con ) se pueden consumir con los Servicios de Invocación de Plataforma (P/Invoke) .extern"C"[DllImport]

El lenguaje de programación D utiliza la modificación de nombres, que se realiza de forma diferente a C++, y produce nombres generalmente más legibles para los humanos. ^{[ 6 ] [ 7 ]} Los nombres se modifican a menos que se enlace con C (usando ). Ofrece una herramienta "ddemangle" para descomponer nombres de símbolos. ^{[ 8 ]} La biblioteca ofrece módulos para modificar símbolos ^{[ 9 ]} y para descomponer símbolos D. ^{[ 10 ]}extern(C)dmd.mangleextern(D)core.demangle

La modificación de nombres también es necesaria en los compiladores de Fortran , originalmente porque el lenguaje no distingue entre mayúsculas y minúsculas . Posteriormente, durante la evolución del lenguaje, se impusieron requisitos adicionales de modificación debido a la adición de módulos y otras características en el estándar Fortran 90. La modificación de mayúsculas y minúsculas, en particular, es un problema común que debe resolverse para llamar a bibliotecas de Fortran, como LAPACK , desde otros lenguajes , como C.

Debido a la insensibilidad a mayúsculas y minúsculas, el nombre de una subrutina o función FOOdebe ser convertido a un formato y mayúsculas estandarizados por el compilador para que se enlace de la misma manera independientemente de las mayúsculas y minúsculas. Diferentes compiladores han implementado esto de diversas maneras, y no se ha producido una estandarización. Los compiladores Fortran de AIX y HP-UX convierten todos los identificadores a minúsculas foo, mientras que los compiladores Fortran de Cray y Unicos los convierten a mayúsculas FOO. El compilador GNU g77 convierte los identificadores a minúsculas más un guion bajo foo_, excepto que a los identificadores que ya contienen un guion bajo FOO_BARse les añaden dos guiones bajos foo_bar__, siguiendo una convención establecida por f2c . Muchos otros compiladores, incluidos los compiladores IRIX de Silicon Graphics (SGI) , GNU Fortran y el compilador Fortran de Intel (excepto en Microsoft Windows), convierten todos los identificadores a minúsculas más un guion bajo ( y , respectivamente). En Microsoft Windows, el compilador Fortran de Intel utiliza mayúsculas por defecto sin guion bajo. ^{[ 11 ]}foo_foo_bar_

Los identificadores en los módulos de Fortran 90 deben ser modificados aún más, ya que el mismo nombre de procedimiento puede aparecer en diferentes módulos. Dado que el estándar Fortran 2003 exige que los nombres de los procedimientos de los módulos no entren en conflicto con otros símbolos externos, ^{[ 12 ]} los compiladores tienden a usar el nombre del módulo y el nombre del procedimiento, con un marcador distintivo entre ellos. Por ejemplo:

El módulo m contiene la función entera five () five = 5 fin de la función five fin del módulo m

En este módulo, el nombre de la función se modificará de la siguiente manera: __m_MOD_five(por ejemplo, GNU Fortran), m_mp_five_(por ejemplo, ifort de Intel), m.five_(por ejemplo, sun95 de Oracle), etc. Dado que Fortran no permite sobrecargar el nombre de un procedimiento, sino que utiliza bloques de interfaz genéricos y procedimientos genéricos ligados a tipos, los nombres modificados no necesitan incorporar pistas sobre los argumentos.

La opción BIND de Fortran 2003 hace que el compilador utilice las reglas de modificación de caracteres utilizadas para otro lenguaje de programación, como C, como se muestra arriba .

En Java , la firma de un método o una clase contiene su nombre y los tipos de sus argumentos y valor de retorno, cuando corresponda. El formato de las firmas está documentado, ya que el lenguaje, el compilador y el formato de archivo .class se diseñaron conjuntamente (teniendo en cuenta desde el principio la orientación a objetos y la interoperabilidad universal).

clase pública Foo { clase Bar { público int x ; }public void baz () { Object f = new Object () { public String toString () { return "hola" ; } }; } }

En Python , el mangling se utiliza para los atributos de clase que no se desea que las subclases utilicen ^{[ 14 ]} , los cuales se designan como tales dándoles un nombre con dos o más guiones bajos iniciales y no más de un guion bajo final. Por ejemplo, __thingse aplicará mangling, al igual que ___thingy __thing_, pero __thing__y __thing___no. El entorno de ejecución de Python no restringe el acceso a dichos atributos; el mangling solo evita colisiones de nombres si una clase derivada define un atributo con el mismo nombre.

Al encontrar atributos con nombres distorsionados, Python transforma estos nombres anteponiendo un guion bajo y el nombre de la clase que los contiene, por ejemplo:

clase Test : def __mangled_name ( self ) -> None : passdef normal_name ( self ) -> None : passif __name == "__main__" : t : Test = Test () print ([ attr for attr in dir ( t ) if "name" in attr ]) # imprime: ['_Test__mangled_name', 'normal_name']

En Objective-C existen esencialmente dos tipos de métodos : el método de clase ("estático") y el método de instancia . La declaración de un método en Objective-C tiene la siguiente forma:

+ ( tipo de retorno ) nombre 0 : parámetro 0 nombre 1 : parámetro 1 ... – ( tipo de retorno ) nombre 0 : parámetro 0 nombre 1 : parámetro 1 ...

Los métodos de clase se representan con +, mientras que los métodos de instancia utilizan -. Una declaración típica de un método de clase podría tener el siguiente aspecto:

+ ( id ) initWithX: ( int ) number andY: ( int ) number ; + ( id ) new ;

Con métodos de instancia que se ven así:

- ( id ) valor ; - ( id ) establecerValor: ( id ) nuevo_valor ;

Cada una de estas declaraciones de método tiene una representación interna específica. Al compilarse, cada método se nombra según el siguiente esquema para métodos de clase:

_c_ Clase _ nombre 0 _ nombre 1 _ ...

y esto por ejemplo métodos:

_i_ Clase _ nombre 0 _ nombre 1 _ ...

Los dos puntos en la sintaxis de Objective-C se traducen a guiones bajos. Por lo tanto, el método de clase de Objective-C , si pertenece a la clase, se traduciría como , y el método de instancia (que pertenece a la misma clase) se traduciría a .+(id)initWithX:(int)numberandY:(int)number;Point_c_Point_initWithX_andY_-(id)value;_i_Point_value

Cada uno de los métodos de una clase se etiqueta de esta manera. Sin embargo, buscar un método al que una clase pueda responder sería tedioso si todos los métodos se representaran de esta forma. A cada método se le asigna un símbolo único (como un número entero). Dicho símbolo se conoce como selector . En Objective-C, se pueden gestionar los selectores directamente; tienen un tipo específico en Objective-C SEL.

Durante la compilación, se crea una tabla que asigna la representación textual, como _i_Point_value, a selectores (a los que se les da un tipo SEL). Gestionar selectores es más eficiente que manipular la representación textual de un método. Tenga en cuenta que un selector solo coincide con el nombre de un método, no con la clase a la que pertenece: diferentes clases pueden tener diferentes implementaciones de un método con el mismo nombre. Debido a esto, a las implementaciones de un método también se les da un identificador específico, estos se conocen como punteros de implementación, y también se les da un tipo, IMP.

El compilador codifica los envíos de mensajes como llamadas a la función, o a una de sus variantes, donde es el receptor del mensaje y determina el método a llamar. Cada clase tiene su propia tabla que asigna selectores a sus implementaciones; el puntero de implementación especifica dónde reside en la memoria la implementación del método. Hay tablas separadas para métodos de clase e instancia. Aparte de estar almacenadas en las tablas de búsqueda, las funciones son esencialmente anónimas.idobjc_msgSend(idreceiver,SELselector,...)receiverSELSELIMP

El SELvalor de un selector no varía entre clases. Esto permite el polimorfismo .

El entorno de ejecución de Objective-C mantiene información sobre los tipos de argumentos y de retorno de los métodos. Sin embargo, esta información no forma parte del nombre del método y puede variar de una clase a otra.

Dado que Objective-C no admite espacios de nombres , no es necesario modificar los nombres de las clases (que sí aparecen como símbolos en los binarios generados).

En Rust , los nombres de las funciones se modifican de forma predeterminada . Sin embargo, esto se puede deshabilitar mediante el #[unsafe(no_mangle)]atributo `function`. Este atributo permite exportar funciones a C, C++ u Objective-C . ^{[ 15 ]} Además, junto con el #[start]atributo `function` o el #![no_main]atributo `crate`, permite al usuario definir un punto de entrada al estilo C para el programa. ^{[ 16 ]}

Rust ha utilizado muchas versiones de esquemas de modificación de símbolos que se pueden seleccionar en tiempo de compilación mediante una -Z symbol-mangling-versionopción. Se definen los siguientes modificadores:

• legacyUn estilo de manipulación de caracteres en C++ basado en la ABI de C++ de Itanium IA-64. Los símbolos comienzan con _ZN, y se utilizan hashes de nombres de archivo para la desambiguación. Se utiliza desde Rust 1.9. ^{[ 17 ]}
• v0Una versión mejorada del esquema anterior, con cambios para Rust. Los símbolos comienzan con _R. El polimorfismo se puede codificar. Las funciones no tienen tipos de retorno codificados (Rust no tiene sobrecarga). Los nombres Unicode usan punycode modificado . La compresión (referencia inversa) usa direccionamiento basado en bytes. Usado desde Rust 1.37. ^{[ 18 ]}

En las symbol-namespruebas de Rust se proporcionan ejemplos. ^{[ 19 ]}

Swift almacena metadatos sobre las funciones (y más) en los símbolos modificados que las identifican. Estos metadatos incluyen el nombre de la función, sus atributos, el nombre del módulo, los tipos de parámetros, el tipo de retorno y más. Por ejemplo:

El nombre modificado para un método func calculate(x: int) -> intde una MyClassclase en el módulo testes _TFC4test7MyClass9calculatefS0_FT1xSi_Si, para Swift 2014. Los componentes y sus significados son los siguientes: ^{[ 20 ]}

• _T: El prefijo para todos los símbolos de Swift. Todo comenzará con esto.
• F: Función no currificada.
• C: Función de una clase, es decir, un método
• 4test: Nombre del módulo, precedido por su longitud.
• 7MyClass: Nombre de la clase a la que pertenece la función, precedido por su longitud.
• 9calculate: Nombre de la función, precedido por su longitud.
• f: El atributo de función. En este caso, 'f', que significa una función normal.
• S0: Designa el tipo del primer parámetro (es decir, la instancia de la clase) como el primero en la pila de tipos (aquí MyClassno está anidado y, por lo tanto, tiene el índice 0).
• _FT: Aquí comienza la lista de tipos para la tupla de parámetros de la función.
• 1x: Nombre externo del primer parámetro de la función.
• Si: Indica el tipo Swift.Int integrado para el primer parámetro.
• _Si: El tipo de retorno: nuevamente Swift.Int.

La modificación de tipos para versiones posteriores a Swift 4.0 está documentada oficialmente. Conserva cierta similitud con Itanium. ^{[ 21 ]}