Re:C and Go without CGO
by 4ad on Wednesday July 30, 2014 @06:08AM
(#8107229)
> 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.
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
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.