Also some highly non-obvious gotchas and notes, straight from the trenches:

- VERY IMPORTANT: you'll be actually writing for a pre-ANSI C compiler! Anything you think you know about C may prove false! Example real-world discrepancy found when porting Lua (an extremely high-quality ANSI C codebase) to Go's cc: http://golang.org/issue/7027

- The ternary operator (?:) is not supported on ARM (see: https://github.com/akavel/goluago/issues/8#issuecomment-4144...)

- You don't have #if, #elif

- You must be super careful, and really know what you're doing, when trying to pass pointers through the C<->Go boundary, as you're entering GC (garbage collector)'s carefully tended house of cards

- You don't have access to the C standard library (although, see https://github.com/akavel/gostdc)

- Using varargs functions is non-trivial

- You must ensure you include one special header in each and every C file (#include "runtime.h") because of special "extern register" variables; although, I'm not sure if this requirement was not removed in Go 1.3.

Hm, that's all I could remember from the top of my head. If you have any questions, feel free to ask me by email ([email protected]) or, obviously, anyone on the golang-nuts mailing list.

That said, it's sure fun! :D actually, maybe in part because of all that :)

> you'll be actually writing for a pre-ANSI C compiler!

I would not say the compiler is pre-ANSI. For example it even has some C99 features. Rather, it chose to ignore ANSI, so yes, you need to really careful with what your doing. The integer promotion rules are different, for example

    -1 < u16int(42)

is false, unlike in ANSI C.

> You must be super careful, and really know what you're doing, when trying to pass pointers through the C<->Go boundary

Yes, however that is true with cgo as well. Especially now with the new precise garbage collector.

> because of special "extern register" variables; although, I'm not sure if this requirement was not removed in Go 1.3.

Nothing changed in 1.3, however big changes are coming into Go 1.4 and Go 1.5. Eventually all the C code in the runtime will go away. Until then, the plan is to move all remaining C code onto the scheduler stack instead of having common Go and C stacks, as that interferes with the copying stacks and the new precise garbage collector.

In other words, using the Plan 9 C compiler in your project uses to work by accident. Not it appears as it would still work, but it actually has a subtle net negative effect that's not obvious to see at first glance. You should avoid it.

Even worse, the C parts of the Go runtime are being rewritten in Go. The Plan 9 C compiler is going away along with all the other C bits as the compilers themselves are being translated to Go.

In short, this will go away very soon. Possibly even Go 1.4. Definitely Go 1.5.

The way he describes linking/including .c files is identical to how you can link-in/include assembly code via .s files. I don't see the latter going away (the standard `math` package uses this extensively), so why should the former---even if Go 1.4 or later itself doesn't use it..

The main Go distribution will always have assembly source files: there are always going to be special instructions or routines, such as low-level startup, that must be written at that level. The same is not true of (non-gcc) C source files.

Once the main Go distribution has no non-gcc C source files, we _will_ delete the Plan 9 C compilers. There is no reason to maintain them if we are not using them.