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.
