[EMAIL PROTECTED] wrote:
>
> | Then unless there are objections from others, I propose that we specify that
> | an XError is generated when a returned function pointer is called in an
> | inappropriate context.
>
> Someone needs to look at the code to make sure, but it might be tricky
> to do this right. (a) The error must be generated on the client side,
> not the server side as is the case with normal XErrors. (b) The error
> is not associated with a particular X request, which may cause
> problems with other code (like existing error handlers) that expects
> the error to have all the usual characteristics of normal XErrors.
Sheesh, that's an excellent point. I have suddenly developed a real
dislike for this option. Allen, I'm glad you're keeping us honest here!
> My inclination would be to punt. There's some efficiency and
> implementation simplicity to be gained by not even testing for the
> failure condition; just fail in the same way any app will fail when it
> dereferences a stray pointer. If that's unacceptable, then I suggest
> we invoke abort() rather than attempt to synthesize either an X or a
> GL error.
I almost agree ;^). I would still prefer to generate a GL_ERROR if
possible, but if I'm the only one that wants this, then I agree with
Allen. So here are the possible options listed in order of my preference:
- Generate a GL_INVALID_OPERATION error when an unsupported context is
bound, and do nothing if no context is bound.
- Just punt, and leave the spec'd behavior as undefined (i.e. an
implementation could just dereference a bogus pointer, and whatever
happens, happens...
- Define the behavior to be that the process aborts.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
