| 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.
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.
Allen
