Slash and dots in function names and prototypes?

I am new to C and am looking at Go source tree. I found this:

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) { // ... } 

What do traits and dots (Ā·) mean? Is it really C?

+18
c go notation
Nov 20
source share
4 answers

IMPORTANT UPDATE:

The final answer , of course, is the one you received from Russ Cox , one of the authors of Go, on the golang-nuts mailing list. However, I leave some of my previous notes below, they can help to understand some things.

In addition, after reading this answer above, I believe that the pseudo-slash āˆ• can now be converted to normal / slash (for example, middot translates to a point) in newer versions of the Go C compiler than the one I tested below, but I don’t have time to check.




The file is compiled The Go Language Suite internal compiler , which occurs in the Plan 9 C (1) (2) compiler and has some differences (mainly extensions, AFAIK) to the C standard.

One of the extensions is that it allows UTF-8 characters in identifiers.

Now, in the Go Language Suite C compiler, the middot (Ā·) character is handled in a special way, because it is converted to a regular dot (.) In object files, which is interpreted by the Go language Suite internal linker as a namespace delimiter character.

Example

For the following example.c file (note: it should be saved as UTF-8 without specification):

 void Ā· Bar1 () {}
 void foo Ā· bar2 () {}
 void foo āˆ• baz Ā· bar3 () {}

the internal C compiler creates the following characters:

 $ go tool 8c example.c
 $ go tool nm example.8
  T "" .Bar1
  T foo.bar2
  T foo āˆ• baz.bar3

Now, please note that I gave Ā·Bar1() capital B This is because in this way I can make it visible to regular Go code - because it translates to the same character that compiles the following Go code:

 package example
 func Bar1 () {} // nm will show: T "" .Bar1

Now, with respect to the functions that you mentioned in the question, the story goes further along the rabbit hole. I am a little less sure that I am here, but I will try to explain based on what I know. Therefore, each sentence below this paragraph should be read as if it were " AFAIK ", written only at the end.

So, the next missing piece, needed to better understand this riddle, is to learn something else about the strange namespace "" and how the Go suite linker is handled. The namespace "" is what we can call "empty" (because "" for the programmer means "empty string"), or maybe better, the "namespace". And when the linker sees the import as follows:

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

then it accepts the library file $GOPATH/pkg/.../example.a , and during the import phase it replaces each "" on the fly with path/to/package/example . So, now in the linked program we will see such a symbol:

  T path / to / package / example.Bar1
+19
Nov 21 '12 at 10:07
source share

The character "Ā·" \xB7 corresponds to my Javascript console. The "/" character is \x2215 .

The point is in the application. D C99 standard contains lists of special characters that are valid as identifiers in C. The slash does not seem, so I suspect that it was used as something else (possibly a namespace) using the magic of #define or a preprocessor .

This explains why the dot is present in the definition of the actual function, but there is no slash.

Edit: Check this box for more information. It is possible that the unicode slash just allows the implementation of GCC.

+8
Nov 20 '12 at 15:07
source share

It seems that this is not the standard C nor C99. In particular, he gcc and clang complains about the point, even in C99 mode.

This source code is compiled by the Part 9 compiler suite (specifically. / Pkg / tool / darwin _amd64 / 6c on OS X), which is loaded by the Go build system. According to this document , at the bottom of page 8, Plan 9 and its compiler do not use ASCII at all, but use Unicode instead. At the bottom of page 9, it is indicated that any character with a sufficiently high code point is considered valid for use in the identifier name.

No magic of preprocessing at all - the definition of functions does not correspond to the declaration of functions simply because they are different functions. For example, void runtimeāˆ•raceĀ·Initialize(); is an external function, the definition of which is contained in. /src/pkg/runtime/race/race.go; similarly for void runtimeāˆ•raceĀ·MapShadow(…) .

The function that comes later, void runtimeĀ·raceinit(void) , is a completely different function, which is aparant by the fact that it actually calls runtimeāˆ•raceĀ·Initialize(); .

+5
Nov 20 '12 at 17:03
source share

The go / runtime compiler compiles using the C compilers originally developed for plan9. When you build the transition from the source, first create plan9 compilers, and then use them to build Go.

Plan9 compilers support Unicode function names [1], and Go developers use Unicode characters in their function names as pseudo-spaces.

[1] It looks like it can really be standards compliant: the variable name is unixode g ++ , but gcc does not support unicode function / variable names.

+3
Nov 21
source share