I haven't tested the series yet, but I will hopefully tomorrow. My main concern is with error handling when __glGetProcAddress() returns NULL.
== 1,4,5 == Ok Reviewed-by: Jeremy Huddleston Sequoia <[email protected]> == 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'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. == 3 == Same concern about __glGetProcAddress returning NULL. == 6,7 == Out of my area, but looks reasonable to me. == 8 == Looks right (but untested). I'd like to see the function renamed from setup_dispatch_table since there is no longer a dispatch table being setup, but I can do that in a followup. Reviewed-by: Jeremy Huddleston Sequoia <[email protected]> On Dec 3, 2013, at 12:14, Adam Jackson <[email protected]> wrote: > This fixes up the indirect glx code to only call-by-name those symbols > present in the Linux OpenGL ABI, which corresponds to OpenGL 1.2.1. > Since that was available even on OSX 10.0 this should be sufficient for > xquartz as well. > > Merely proven correct, not tested. The xwin code assuredly needs > something similar. I don't entirely understand the scary-looking comment > in there about stdcall, and I'm quite sure the existing code is broken > for multiple indirect contexts since wglGetProcAddress results are > context-sensitive unlike GLX. > > - ajax > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
