Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: do really debug functions work? #116

Open
hajimehoshi opened this issue Oct 26, 2018 · 3 comments
Open

Question: do really debug functions work? #116

hajimehoshi opened this issue Oct 26, 2018 · 3 comments
Labels

Comments

@hajimehoshi
Copy link
Member

hajimehoshi commented Oct 26, 2018

For example, in the current DebugMessageCallback implementation, Go function's pointer is converted to a C pointer:

func DebugMessageCallback(callback DebugProc, userParam unsafe.Pointer) {
	userDebugCallback = callback
	C.glowDebugMessageCallback(gpDebugMessageCallback, (C.GLDEBUGPROC)(unsafe.Pointer(&callback)), userParam)
}

I was wondering if this really works, and anyone tests this. I found #40 , and perhaps these functions don't work now?

@hajimehoshi hajimehoshi changed the title Question: does really debug functions work? Question: do really debug functions work? Oct 26, 2018
@dmitshur
Copy link
Member

I have never used any of the *Debug* functions in gl, so I can't say.

@pwaller
Copy link
Member

pwaller commented Mar 30, 2019

Further reference: go-gl/glow#3

It does look strange, but I believe can work. If you dig into it, you find that glowDebugMessageCallback ignores its callback parameter.

I don't know why there is a callback parameter. One thought I had was that it could be to prevent garbage collection of the function value, but I guess that doesn't make sense because the function value is stored in userDebugCallback.

@errcw could you shed light on the callback parameter? Could it be eliminated from C.glowDebugMessageCallback`, or otherwise could we add a comment explaining its reason for existence?

@errcw
Copy link
Member

errcw commented Mar 30, 2019

If I remember correctly it's simply an artifact of the code generation, i.e., it just takes the C definition so ends up with an extraneous parameter that is dropped so the C/Go machinery works. It would be a reasonable enhancement to add a comment or, even better, remove the unused parameter entirely (though if it involves too much special casing I'd be wary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants