----- Original Message -----
From: Jon Leech <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 04, 1999 9:42 AM
Subject: Re: [oglbase-discuss] New GLX_ARB_get_proc_address specification
>
> > I would prefer to see an error or nop function returned so when
> > calling an ARB_get_proc_address functions the behavior is
> > similiar to calling GL functions without a current context.
> > I don't recall offhand what GL noncurrent context functions do.
>
> In general, undefined. Since we can now query *any* entry point, and
> since error semantics are different for GL, GLX, and GLU entry points,
> the only meaningful consistent (e.g. specifiable) behavior you could
> require is "termination" or "noop". I don't think "noop" is useful to
> the ISV;
with context independance, since you cannot know what FUTURE contexts will
be created, you must return a non-NULL dispatcher proc. The only open
question is whether an unsupported EXT should be dispatched to a noop or
error-generating function.
> consider the scenario:
>
> #ifdef GL_ARB_multitexture
> /* Verify that GL_EXTENSIONS contains ARB_multitexture */
> if (gluCheckExtension("GL_ARB_multitexture",
> glGetString(GL_EXTENSIONS))
> {
> /* Valid ptr to "noop" function returned (note typo)*/
> activetexptr = glXGetProcAddressARB("glActiveTextureARV");
> }
> #endif
> ...
> (*activetexptr)(GL_TEXTURE2_ARB); /* Oops, noop */
> ... further calls affect/use texture 0 instead of texture 2
This IS a bug since the app DIDN'T stor the check extension result and is
assuming it is extant. If we returned NULL as you suggest then on some
untested platform missing a prereq. extension the app crashes -- YUCK!
>
> Now the app silently gets incorrect behavior, yet when the ISV
> attempts to debug it, the call succeeds and the actual problem is far
> removed from where it *seems* to be! So having a checkable
> success/failure flag (NULL return) on the call seems desirable to me.
I thought that the return value from getProc was NOT supposed to be
interpreted as an exsistance flag for any extension. To solve the "silent
failure" problem returning a error noop would give the application a way to
track this down without building crash.
I say we require a NON-null return (that is in fact the only truely context
independent possibility) which will either noop or error (to address your
concern). This removes the requirement for NULL test AND the temptation to
incorrectly associate getProc with getString as the appropriate means to
determine exsistance of an extension.
