Re: get_program_iv_arb and friends

[Ian R. <id...@us...>]

Jon Smirl wrote:

> --- Ian Romanick <id...@us...> wrote:
> 
>>Here's the deal.  glXGetProcAddress *NEVER* returns NULL.  It returns a 
>>pointer to a dispatch function.  If you request an unknown function, it 
>>will dynamically generate a dispatch for it.  Try calling 
>>'glXGetProcAddressARB((const GLubyte*)"glThisFunctionDoesntExist");". 
>>Getting a pointer back isn't enough.  You have to look at the extension 
>>string to be sure the extension is supported.  If I'm not mistaken, the 
>>GLX spec says that calling a function for an unsupported extension give 
>>"undefined" behavior.
> 
> Why do you dynamically generate a dispatch for unknown functions instead of just
> returning null? What does this dispatch dispatch to?

Because you can call glXGetProcAddress without a GL context, and the 
driver can export functions that libGL doesn't know about.  For example, 
the first line in main could be 'foo = 
glXGetProcAddress("glVertexBlendARB");'.  None of the open-source 
drivers support ARB_vertex_blend, but the ATI drivers do.  At that 
point, libGL has no way of knowing what the driver will export.

You also have the opposite case.  libGL might have a dispatch stub for 
glBufferDataARB, but the driver might not support it.  If it doesn't 
support it, it doesn't have to put anything in the dispatch table.  In 
fact, if the function was added to the standard dispatch table after the 
driver was built, the driver won't even know the function exists so that 
it can put something in the dispatch table.

Besides, the purpose of glXGetProcAddress is not to determine if an 
extension is available.  It exists solely to resolve linkage issues 
(basically).