glActiveTextureARB: pointer vs function

The place to discuss creating, porting and modifying Celestia's source code.
Topic author
Brian Paul

glActiveTextureARB: pointer vs function

Post #1by Brian Paul » 06.11.2002, 15:47

I spent a few hours trying to figure out why Celestia was crashing in glActiveTextureARB on XFree86/DRI with indirect rendering. I found the problem. I think it should be addressed in Celestia.

The src/celengine/glext.h file defines a number of function pointers which have names that are identical to OpenGL function names:

extern PFNGLMULTITEXCOORD2IARBPROC glMultiTexCoord2iARBptr;
extern PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARBptr;
extern PFNGLMULTITEXCOORD3FARBPROC glMultiTexCoord3fARBptr;
extern PFNGLMULTITEXCOORD3FVARBPROC glMultiTexCoord3fvARBptr;
extern PFNGLACTIVETEXTUREARBPROC glActiveTextureARBptr;
extern PFNGLCLIENTACTIVETEXTUREARBPROC glClientActiveTextureARBptr;

It turns out that this confuses the linker/loader at some point. I.e. is glActiveTextureARB a library function or global pointer? It's both! That's bad. Suppose one declared a function pointer named 'printf' - you can see how that might lead to problems.

My suggestion to the Celestia developers is to suffix their function pointers with "ptr" or something else like this glActiveTextureARBptr.

Also, I see that these function pointers are only initialized if the GL_ARB_multitexture extension is available. What happens when you call glActiveTextureARB() without first initializing that pointer? If GL_ARB_multitexture is not supported, glActiveTextureARBptr should point to a no-op function (or be 100% certain you never try to use that pointer).

After I made this change locally, the crash in glActiveTextureARB stopped and Celestia ran fine.

If you have any questions about this please contact me at brian@tungstengraphics.com. I don't plan to monitor this forum.

Thanks.

-Brian Paul

Return to “Development”