Comment 1:

interesting.

Labels changed: added release-go1.3, repo-main.

Status changed to Accepted.

Comment 2:

A simpler repro without cgo, two files: z0.c and z1.go
$ cat z0.c
void *·aaaa = (void *)42;
$ cat z1.go
package main
import "unsafe"
var aaaa unsafe.Pointer
var bbbb unsafe.Pointer = aaaa
func main() {
    println(bbbb)
}
$ go tool 6c z0.c
$ go tool 6g z1.go
$ go tool pack grc z.a z0.6 z1.6
$ go tool 6l z.a
$ ./6.out
0x0
Somehow the gc compile thinks that aaaa is zero, so no need to assign to bbbb.
(This bug seems to have always been there, as even Go 1.0 has it)

Comment 3:

The static init code in cmd/gc assumes that if you have
var x = 1
var y = x
then it is okay to infer that var y = 1.
Similarly it assumes that if you have
var x int
var y = x
then it is okay to infer that y = 0. It can't see that you intend to set x behind the
compiler's back.
The workaround is to initialize the variable in a func init block:
var x int
var y int
func init() {
    // x set elsewhere
    y = x
}
I think that's fine for now, honestly. This does not come up very often, as evidenced by
the fact that the behavior produced no complaints for years.
Logically you can think about it as C.f being initialized during an init block itself,
so you have to wait until init blocks to use it.

Status changed to WorkingAsIntended.

Comment 4:

my contrived repro could be regarded as WAI, but the reason for the original issue is
much more difficult to see. We should do something there (for example, we can rewrite
every variable initialized with cgo into a function call (or any other form that force
the
gc to re-evaluate it at runtime):
e.g.
var f = C.f
is translated to:
var f = func() unsafe.Pointer { return __cgo_fp_f }()
What do you think?

Status changed to Thinking.

Comment 5:

Or perhaps we could have cgo simply reject attempts to initialize a Go global variable
with a C variable.

Comment 6:

I'm sorry; I should have posted my original use case; perhaps minux realized this but
I'm not sure:
https://github.com/andlabs/ui/blob/22315bca596b4607b6f63e2746dda9f942008dad/area_darwin.go#L32
In this scenario, I'm building an Objective-C class to talk to Cocoa at runtime. Each of
these function pointers are actually //export-ed Go functions defined later in the same
file. If I remove the uintptr conversions, the function pointers become NULL and either
class creation fails or the program crashes when one of these selectors gets called (I
forget which now).

Comment 7:

CL https://golang.org/cl/93200044 mentions this issue.

Comment 8:

This issue was closed by revision e5c1050.

Status changed to Fixed.

Comment 9:

CL https://golang.org/cl/165400043 mentions this issue.