cmd/cgo: function pointers are assignable

[DanielMorsing]

Function pointers from the cgo package are assignable. I'd expect them to be constants.

example:

package main

/*
#include <stdlib.h>
char *foo() { return NULL; }
*/
import "C"

import "fmt"
import "unsafe"

func main() {
    C.foo = unsafe.Pointer(uintptr(2))
    fmt.Printf("%v\n", C.foo)
}

output:
0x2

[ianlancetaylor]

Comment 1:

I suppose we could detect that case in rewriteRef and have cgo give an error.

Labels changed: added repo-main, release-none.

[DanielMorsing]

Comment 2:

Would it be possible to emit a constant instead?

[ianlancetaylor]

Comment 3:

How could we emit a constant?  cgo is generating Go code, and there is no Go constant
that can represent a C function pointer.

[DanielMorsing]

Comment 4:

cgo uses unsafe.Pointer for function pointers. You can make a constant one of those.
http://play.golang.org/p/ked5QOYfx8

[DanielMorsing]

Comment 5:

I doubt that the code is there for figuring out the eventual address of the function
entry though. rewriteRef route is probably easier to implement.

[ianlancetaylor]

Comment 6:

Interesting example in comment #4.  Filed issue #7760.

[mdempsky]

Comment 7:

I don't think we can use Go consts here, because they need to be known at compile-time,
whereas a C function's address won't be known at least until link-time (and possibly not
until run-time).
However, two possible ways to address this problem (both of which ultimately defer to
the Go compiler to reject assignments to C.foo):
1. Instead of emitting C.foo as "_Cfpvar_fp_foo", emit it as
"unsafe.Pointer(_Cfpvar_fp_foo)".  The explicit conversion would make it
non-addressable.  (I'd probably actually emit as "_Cgo_pointer(_Cfpvar_fp_foo)" and
change the "type _ unsafe.Pointer" in _cgo_gotypes.go to "type _Cgo_pointer
unsafe.Pointer" to avoid worrying about whether package "import" is available in the
user code.)
2. Emit it as a function call like "_Cfpvar_fp_foo()" and change _Cfpvar_fp_foo into a C
function that returns the address of 'foo'.

[gopherbot]

Comment 8:

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

[ianlancetaylor]

Comment 9:

This issue was closed by revision 11016f6.

Status changed to Fixed.