Re: [go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

That makes sense. The upstream API implication, then, would be both GoGlDrawElements(..., unsafe.Pointer) & GoGlDrawElementsWithOffset(..., unitptr) are necessary; that is, there can be no 1:1 Go mapping of the C API. There is an argument to be made that the more explicit Go API is better anyhow.

Re: [go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

On Mon, Feb 19, 2018 at 3:09 PM, Eric Woroshow 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

Re: [go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

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

Re: [go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

On Mon, Feb 19, 2018 at 8:35 PM Eric Woroshow 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).