On Mon, Feb 19, 2018 at 3:09 PM, Eric Woroshow <eric.woros...@gmail.com> wrote: > > 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 there does > not (yet) exist a good way to treat C memory as a slice.
There just isn't any good solution here. In C it's fine for a variable to be either a pointer or an integer. In Go it must be one or the other. One approach you can sometimes take is to write a little C helper function, perhaps in the cgo comment itself, that uses the correct type from Go's point of view and calls the real C function using a cast to the type that C expects. Ian > 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> 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. -- 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.
