Surprisingly enough, I'm getting a compilation error instead with Go 1.5.2:

$ go version
go version go1.5.2 darwin/amd64

$ go run main.go
# command-line-arguments
./main.go:13: cannot use ptr (type **C.Bar) as type *unsafe.Pointer in argument to _Cfunc_Foo

The wrapper has been generated as:

func _Cfunc_Foo(p0 *unsafe.Pointer) (r1 _Ctype_void)

The workaround is to pass it as ptr := (*unsafe.Pointer)(unsafe.Pointer(arg)) which looks strange but works. In either 1.5.2 or 1.6beta1.

cgo treats this as a type error because a pointer to void is handled as unsafe.Pointer. Since you have typedef void Bar, the C type Bar* is the Go type unsafe.Pointer, and the C type Bar** is the Go type *unsafe.Pointer.

The fix for Go 1.6 is to report an error at compile time rather than at run time, as Go 1.5 does.

Turns out to be hard to check at compile time, for exactly the reason that helper cgoCheckPointer functions were introduced, so postponing to 1.7.

@ianlancetaylor, should this be postponed to Go 1.8?

Dropping to unplanned. I would like to have better compile time checking but I'm not sure how to do it.

This doesn't appear to even require a double-pointer. A plain old void* - as for C.free - suffices. I think this implies that every program that calls C.free on a typed parameter ends up triggering the panic.

For example, this program panics:

package main

/*
#include <stdlib.h>
*/
import "C"
import "unsafe"

func main() {
    var dt *C.div_t
    dt = (*C.div_t)(C.malloc(C.size_t(unsafe.Sizeof(*dt))))
    defer C.free(dt)
}

whereas this one does not:

package main

/*
#include <stdlib.h>
*/
import "C"
import "unsafe"

func main() {
    var dt *C.div_t
    dt = (*C.div_t)(C.malloc(C.size_t(unsafe.Sizeof(*dt))))
    defer C.free(unsafe.Pointer(dt))
}

Yes. The first program is invalid, the second is not. The way to fix this bug is to catch the invalid case at compile time rather than execution time. In Go 1.5 and earlier we caught the invalid case at compile time, but unfortunately the cgo checks broke that. And, even more unfortunately, it's hard to fix. At least, I don't see how to fix it.

I'm sure I'm missing something, but why do the _cgoCheckPointer calls need to be inline in the function parameters at all?

For the example above, cgo generates this code:

func _cgoCheckPointer0(p interface{}, args ...interface{}) unsafe.Pointer {
        return _cgoCheckPointer(p, args...).(unsafe.Pointer)
}

func _Cfunc_free(p0 unsafe.Pointer) (r1 _Ctype_void) {
        _cgo_runtime_cgocall(_cgo_188eb01e039f_Cfunc_free, uintptr(unsafe.Pointer(&p0)))
        [...]
}

[...]

func main() {
        var dt *_Ctype_struct___0
        dt = (*_Ctype_struct___0)(_Cfunc__CMalloc(_Ctype_size_t(unsafe.Sizeof(*dt))))
        defer _Cfunc_free(_cgoCheckPointer0(unsafe.Pointer(dt)))
}

Why does the _cgoCheckPointer call need to occur on the caller side of _Cfunc_free? It seems like we could fix both this issue and #15921 by instead emitting:

func _Cfunc_free(p0 unsafe.Pointer) (r1 _Ctype_void) {
        _cgoCheckPointer0(p0)
        _cgo_runtime_cgocall(_cgo_188eb01e039f_Cfunc_free, uintptr(unsafe.Pointer(&p0)))
        [...]
}

[...]

func main() {
        var dt *_Ctype_struct___0
        dt = (*_Ctype_struct___0)(_Cfunc__CMalloc(_Ctype_size_t(unsafe.Sizeof(*dt))))
        defer _Cfunc_free(dt)
}

Is the problem that the generated function generally accept C types but we need/want to elide the pointer checks based on the corresponding Go types? If that's the case, perhaps we could move the checks to the _Cfunc side only for parameter types that must be transformed between the two.

The problem with your suggestion is that given a pointer to an element in a slice, we only want to check that slice. Given a pointer to a field, we only want to check that field. We only know the extent of the area of memory to check at the call site, not in the wrapper. This extent is expressed as additional arguments to cgoCheckPointer. See #14210 for relevant examples.

Ok. So it's not just type information, but also information about the origins of the values: a *foo that points to an element of a []foo needs a different check from a *foo that points to a member of a struct.

And presumably we need call sites to remain expressions (not statements), because the result of a C function call could itself be a function parameter. So we can't pull the _cgoCheckPointer calls out into separate statements unless they're in a func literal.

...and we can't use func literals because we can't necessarily name the return-type in the current file (if the type happens to include unsafe.Pointer). So now I understand where the _cgoCheckPointer0 function comes from.

So what about the definition of _cgoCheckPointer0 itself? Is there a reason the first arg needs to be an interface{} when we know we're just going to pass it through the runtime and type-assert it to something else?

In src/cmd/cgo/out.go, could we change

  fmt.Fprintf(fgo2, "\nfunc %s(p interface{}, args ...interface{}) %s {\n", n, t)

to

  fmt.Fprintf(fgo2, "\nfunc %s(p %s, args ...interface{}) %s {\n", n, t, t)

?

Yes, I think we could change the _cgoCheckPointer0 function to specify the type of the first parameter. I think I didn't do that because I thought of _cgoCheckPointer0 as essentially the same as the generic function _cgoCheckPointer, and the latter function necessarily has a first argument of type interface{}.

Ah, I see what you mean; that fixes this issue. Thanks! I'll try that--maybe I've forgotten some reason it won't work.

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