Where is this stated? Where is it said that it's technically incorrect?
Just to be clear, I'm not passing it and then running a thread in C that just runs with the pointer to an object that no longer exists in Go. Instead I'm calling a C function synchronously -- there is no possible way the element is going to be collected during that run. It could be compacted (though Go up until now has explicitly had a non-compacting GC, so not a current risk), of course, which is what brought up this issue, but that's the reason such interop languages have pinning (flagging that something shouldn't be moved).
It wasn't by chance -- it was by design, and it was purposefully understanding the lifetime of objects.
The problem is that we hope to move toward a concurrent GC. That means that GC must be able to run concurrently with a long-running cgo call--otherwise a call to some C function that never returns for perfectly valid reasons will block GC forever. And when we have a concurrent moving GC, it is no longer possible to casually pass a Go pointer to C.
In other words, we want to make the Go garbage collector work much better for Go programs, and we don't want calling C to prevent that.
Although the actual plan is not nailed down, I suspect that we will permit passing a Go pointer to C as long as the memory to which that pointer points does not itself contain any Go pointers. The cgo interface will be permitted to either pin the pointer for the duration of the call, or to copy the data to a pinned memory area--your program won't know which will happen.
If you need something more complex to work, you will have to allocate the memory on the C side. It's always OK to pass C pointers to C.
> +rsc
> Passing a Go pointer like that to C is problematic because eventually
> we will want the garbage collector to be able to move things
>> In my opinion, the current behavior should be covered by the
>> compatibility guarantee. In Go 1, passing pointers to Go-allocated
>> memory into C was not a problem.
>
> This was never fully working. Only some individual cases were working.
https://code.google.com/p/go/issues/detail?id=6397#c11
That said, the rule is clearly changing now, and it is not even clear to what it is changing yet (see Ian's comment in this HN thread).
If I am not mistaken, it was discussed on the go-dev group.
Currently on the phone, cannot search properly for it.
EDIT: Now at home. This was the discussion thread
https://groups.google.com/forum/#!topic/golang-dev/pIuOcqAlv...
I think there's another design doc being worked on that will document the situation, and possibly have proposals to make sharing memory between Go and C more convenient. There's are many projects that make heavy use of this, where copying is slow or infeasible, and malloc is inconvenient.