On Tue, 2013-12-03 at 17:18 -0800, Jeremy Huddleston Sequoia wrote: > == 2 == > I didn't check line by line, but the pattern looks reasonable if one > assumes that __glGetProcAddress won't return NULL in any of these > cases. Can we make such a guarantee (ie, will a GLX extension not be > advertised unless the corresponding dependent OpenGL extension is > available)? What is to prevent someone from intentionally crashing > the server by triggering a call to a GLX function which doesn't have > the backing OpenGL functionality available in libGL?
I should probably have linked to the changes to the codegen code: http://cgit.freedesktop.org/~ajax/mesa/log/?h=glapi The GetProcAddress thing is a valid point. glXGetProcAddress never returns NULL. [ew]glGetProcAddress apparently can, so we have to consider it possible. And there's nothing to prevent a client from constructing protocol that calls an entrypoint that the renderer doesn't support. In fact all it needs to do is create an indirect context and call the function, libGL doesn't check this on the client side. Probably it makes sense to check for this in __glGetProcAddress and simply return a stub function there, rather than force each DDX to handle it. > I'd prefer that we cache these results instead of essentially calling > into dlsym (or relying on dlsym's cache), but I am satisfied by > abstracting that away and saying that the caching is the > responsibility of the GPA routine. In fact, now that I've thought > about it, I think I agree that NOT caching the results in dix is the > right approach. I'm of two minds about it, I could be convinced either way. We could cache them at the DIX level by just changing the function pointers to be static instead of auto. I didn't do that because wglGPA function pointers are per-context and I was assuming that's what the xwin ddx would use directly. But as Jon pointed out we have to jump through stub functions to translate calling conventions. So if _those_ stubs call wglGPA afresh every time, the dix level code could safely cache. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
