Right, declaring the type as uintptr but requiring that the memory come 
from C.malloc is workable, but definitely compromises ease-of-use. 
Typically the pointer values are to data stored in slices, and per issue 
13656 <https://github.com/golang/go/issues/13656> there does not (yet) 
exist a good way to treat C memory as a slice.

On Monday, February 19, 2018 at 12:03:00 PM UTC-8, Jan Mercl wrote:
> On Mon, Feb 19, 2018 at 8:35 PM Eric Woroshow <eric.w...@gmail.com 
> <javascript:>> wrote:
> > Using uintptr might work, but my concern is that passing a Go pointer 
> into C by way of a uintptr value might confuse the GC (specifically, that 
> the memory would fail to be pinned if/when Go implements a moving GC).
> Uintptr is an integer type like any other. The GC does not care about 
> integer values. However, the concern about Go objects being moved is valid 
> as the Go compiler already does that in certain cases (stack allocs, but 
> it's not specified when they occur) and, IIRC, pins only unsafe.Pointers 
> passed to the CGO call. In such scenarios it might be possible to use a 
> custom memory allocator to guarantee the stability of the 
> passed-via-uintptr address. Or one can simply use C.malloc, provided the 
> CGO call overhead is not prohibitive. In both cases, there's another 
> possible problem: the out-of-Go-runtime-control allocated Go object cannot 
> contain pointers to any Go-runtime-controlled Go objects as those pointers 
> will not be updated when the pointees are eventually moved (credit Ian 
> Taylor for this valuable notice).
> -- 
> -j

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to