gratis - cs go twitter

¿Barras y puntos en nombres de funciones y prototipos? (4)

Soy nuevo en C y mirando el árbol de fuentes de Go encontré esto:

https://code.google.com/p/go/source/browse/src/pkg/runtime/race.c

void runtime∕race·Read(int32 goid, void *addr, void *pc); void runtime∕race·Write(int32 goid, void *addr, void *pc); void runtime·raceinit(void) { // ... }

¿Qué significan las barras y puntos (·)? ¿Esto es válido C?

ACTUALIZACIÓN IMPORTANTE:
La respuesta definitiva es, sin duda, la que recibió de Russ Cox , uno de los autores de Go, en la lista de correo de golang-nuts. Dicho esto, les dejo algunas de mis notas anteriores a continuación, pueden ayudar a entender algunas cosas.
Además, al leer esta respuesta vinculada anteriormente, creo que la p "pseudo-barra" ahora puede traducirse a regular / slash también (como el middot se traduce en punto) en versiones más nuevas del compilador Go C que la que he probado A continuación, pero no tengo tiempo para verificar.

El compilador interno C de Go Language Suite compila el archivo, que se origina en el compilador C ⁽¹⁾ Plan 9 ^{(1) (2)} , y (1) (en su mayoría, AFAIK) con el estándar C.

Una de las extensiones es que permite caracteres UTF-8 en los identificadores.

Ahora, en el compilador C de Go Language Suite, el carácter middot (·) se trata de una manera especial, ya que se traduce a un punto regular (.) En archivos de objetos, lo que es interpretado por el enlazador interno de Go Language Suite como separador de espacio de nombres. personaje.

Ejemplo
Para el siguiente archivo example.c (nota: debe guardarse como UTF-8 sin BOM):
void ·Bar1() {} void foo·bar2() {} void foo∕baz·bar3() {}
El compilador interno de C produce los siguientes símbolos:
$ go tool 8c example.c $ go tool nm example.8 T "".Bar1 T foo.bar2 T foo∕baz.bar3
Ahora, tenga en cuenta que le he dado a ·Bar1() una B mayúscula. Esto se debe a que de esa manera, puedo hacerlo visible para el código Go normal, ya que se traduce exactamente al mismo símbolo que se obtendría al compilar el siguiente código Go:
package example func Bar1() {} // nm will show: T "".Bar1

Ahora, con respecto a las funciones que nombraste en la pregunta, la historia va más allá del agujero del conejo. Estoy un poco menos seguro de si estoy aquí, pero intentaré explicarlo según lo que sé. Por lo tanto, cada oración debajo de este punto debe leerse como si tuviera " AFAIK " escrito justo al final.

Entonces, la siguiente pieza faltante necesaria para comprender mejor este enigma, es saber algo más sobre el "" espacio de nombres extraño, y cómo lo maneja el enlazador de la suite Go. El "" espacio de nombres es lo que podríamos querer llamar un espacio de nombres "vacío" (porque "" para un programador significa "una cadena vacía"), o quizás mejor, un espacio de nombres de "marcador de posición". Y cuando el enlazador ve una importación como esta:

import examp "path/to/package/example" //... func main() { examp.Bar1() }

luego toma el archivo de biblioteca $GOPATH/pkg/.../example.a , y durante la fase de importación sustituye sobre la marcha cada "" con path/to/package/example . Así que ahora, en el programa vinculado, veremos un símbolo como este:

T path/to/package/example.Bar1

El carácter "·" es /xB7 acuerdo con mi consola de Javascript. El carácter "" es /x2215 .

El punto se encuentra dentro del Anexo D de la lista estándar de C99, cuyos caracteres especiales son válidos como identificadores en C fuente. La barra diagonal no parece ser así, así que sospecho que se usa como otra cosa (quizás espacios de nombres) a través de #define o preprocesador mágico.

Eso explicaría por qué el punto está presente en la definición de la función real, pero la barra diagonal no lo está.

Editar: Marque esta respuesta para obtener información adicional. Es posible que la barra diagonal de Unicode esté permitida por la implementación de GCC.

El compilador / tiempo de ejecución go se compila utilizando los compiladores de C desarrollados originalmente para plan9. Cuando compile go from source, primero compilará los compiladores plan9, luego los usará para compilar Go.

Los compiladores plan9 admiten nombres de funciones Unicode [1], y los desarrolladores de Go usan caracteres Unicode en sus nombres de funciones como pseudo espacios de nombres.

[1] Parece que esto podría cumplir con los estándares: nombre de variable g + unicode, pero gcc no admite nombres de función / variable de unicode.

Parece que esto no es estándar C, ni C99. En particular, tanto gcc como clang quejan del punto, incluso en el modo C99.

Este código fuente es compilado por el conjunto de compiladores de la Parte 9 (en particular, ./pkg/tool/darwin_amd64/6c en OS X), que es iniciado por el sistema de compilación Go. Según este documento , en la parte inferior de la página 8, Plan 9 y su compilador no usan ASCII en absoluto, sino que usan Unicode en su lugar. En la parte inferior de la página 9, declaró que cualquier carácter con un punto de código suficientemente alto se considera válido para su uso en un nombre de identificador.

No hay magia de preprocesamiento en absoluto: la definición de funciones no coincide con la declaración de funciones simplemente porque son funciones diferentes. Por ejemplo, void runtime∕race·Initialize(); es una función externa cuya definición aparece en ./src/pkg/runtime/race/race.go; de la misma manera para void runtime∕race·MapShadow(…) .

La función que aparece más adelante, void runtime·raceinit(void) , es una función completamente diferente, que es aparente por el hecho de que en realidad llama runtime∕race·Initialize(); .