Stephen J Baker wrote:
>
> On Wed, 8 Nov 2000, Brian Paul wrote:
>
> > 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.
>
> I don't think you should rely on that. It's "undefined" - which
> means anything from a No-op to a core dump.
Right, no one should rely on that. I'm just saying what happens now.
> > > 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.
>
> Exactly.
>
> > 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.
>
> I think it should abort - otherwise people will write programs
> (badly) using Mesa and wonder why they crash on other OpenGL's.
>
> I'm not a great fan of (potentially) burdening drivers with
> the need to operate correctly in the face of a broken application.
> Whilst it's nice to hear that Mesa can provide a clean fallback
> for missing functions - I don't think we should require other
> OpenGL implementations to do the same.
I don't care what other OpenGL implementations do.
If the Linux/ABI spec determines that there should be a particular
behaviour I'll do whatever it says, of course.
Otherwise, I've got more important things to work on.
-Brian
