Code that uses unsafe.Pointer to convert an integer-typed value held in memory into a pointer is illegal and must be rewritten

[Wessie]

This issue made because go-gl/gl#18 is the wrong repository for it.

This is the exact same issue that had to be resolved back in the old bindings go-gl/glfw#78, the most straightforward fix would be to work with uintptr instead of unsafe.Pointer. Using a new type instead of uintptr is also viable, but in no circumstance should it stay in an unsafe.Pointer

[errcw]

For the record, the offending code is part of the conversions template.

The trouble is that when glow generates Go bindings for functions like glVertexAttribPointer it converts the const GLvoid * pointer parameter into unsafe.Pointer which is arguably the most reasonable type. However the pointer represents an offset not a memory address thus runs afoul of the Go unsafe.Pointer requirements. Unfortunately it's not clear how to adjust the Go type without more contextual information or a special case; the spec XML does not offer any relevant hints. We may simply need to bite the bullet and add "type hints".

[4ydx]

If I try to build my project using -race, then I seem to be seeing this issue. Or am I mistaken?

gl.VertexAttribPointer(
world.Program.NormalCoordinate, 3, gl.FLOAT, false, indexLength*4, gl.PtrOffset(3 * 4),
)

Results in:

runtime: writebarrierptr *0xc4200511a0 = 0xc
fatal error: bad pointer in write barrier

runtime stack:
runtime.throw(0x478b4cc, 0x1c)
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/panic.go:566 +0x95
runtime.writebarrierptr.func1()
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/mbarrier.go:151 +0xbd
runtime.systemstack(0x4a5a600)
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/asm_amd64.s:298 +0x79
runtime.mstart()
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/proc.go:1079

goroutine 1 [running, locked to thread]:
runtime.systemstack_switch()
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/asm_amd64.s:252 fp=0xc4200510d0 sp=0xc4200510c8
runtime.writebarrierptr(0xc4200511a0, 0xc)
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/mbarrier.go:152 +0x7b fp=0xc420051108 sp=0xc4200510d0
runtime.assertE2T(0x46bc6a0, 0x46bc6a0, 0xc, 0xc4200511a0)
/usr/local/Cellar/go/1.7.1/libexec/src/runtime/iface.go:248 +0x77 fp=0xc420051160 sp=0xc420051108
github.com/go-gl/gl/v3.3-core/gl._cgoCheckPointer0(0xc, 0x0, 0x0, 0x0, 0x0)
github.com/go-gl/gl/v3.3-core/gl/_obj/_cgo_gotypes.go:1533 +0x9e fp=0xc4200511b8 sp=0xc420051160
github.com/go-gl/gl/v3.3-core/gl.VertexAttribPointer(0x300000001, 0x1406, 0xc40000002c, 0xc)
/Users/user/go/src/github.com/go-gl/gl/v3.3-core/gl/package.go:8091 +0x71 fp=0xc420051200 sp=0xc4200511b8

[dertseha]

With the presence of overloads and the first overlad functions available, is there still a need to consider reflect.Uintptr within Ptr()?

Or should this be kept for pre-1.14 compatibility, and a complete removal would happen in a properly tagged release?

[errcw]

I think the deprecation route makes the most sense to me.

[ZegWe]

hello, I'm a newbie to OpenGL, and I'm using VertexAttribPointer in my program, which has some problem according to this issue. Now I wonder what I should use as the substitute of VertexAttribPointer.

[dertseha]

Hi, @ZegWe ; For this function there's the safe alternative VertexAttribPointerWithOffset, which you should use instead.
See the corresponding paragraph in the readme for details.