Jon Leech wrote:
>
> On Fri, Nov 03, 2000 at 10:19:37AM -0800, Ron Bielaski wrote:
> > Can someone help refresh my memory about what happens when an
> > extension function exists in the library and is called but is
> > not supported by the device?
>
> If you mean specifically WRT the Linux ABI, the correct answer at
> this point is "whatever Brian's implementation in XFree86 4 does".
It'll be a no-op. Both in XFree86/DRI and stand-alone Mesa.
> There
> was some contentious discussion on this ca. Nov. 5 1999 on the mailing
> list, in the context of "if I get a pointer back from
> glXGetProcAddressARB and call it with a context current that doesn't
> support that extension, what should happen?"
>
> In the abstract spec sense, behavior when calling an unsupported
> extension is undefined by the GL and GLX Specifications.
>
> > Is this a noop or error?
>
> It's an application error; making such an invalid call doesn't even
> necessarily fall under the "will not terminate the GL" caveat in the
> Specification IMO. More benign failure modes, such as returning
> GL_UNSUPPORTED_OPERATION or generating a GLX error, are probably
> desirable when possible - but they aren't always possible.
>
> > I didn't notice a description in the spec or an issue and wasn't
> > able to determine the outcome in the mail archive.
>
> I don't believe we had resolution, or if we did, it wasn't
> documented. This needs to be pinned down in the ABI and the
> glXGetProcAddressARB specifications.
I found it to be a simple matter to initialize all dispatch tables
with pointers to no-op functions. The no-op function could easily
be modified to abort or print an error message, but I'd like to
keep it a plain no-op.
-Brian
