Jon Leech wrote:
>
> I could live with that. If someone has a *specifiable* and
> *meaningful* way of generating an error, I could go for that too - but I
> cannot see how to, and all people have been saying is "generate an
> error" without providing details. So what type of error should calling
> through the "yo-mama" function pointer generate? The answer might be
> easier if had separate queries for GLX and GL functions, but we don't
> now...
What's wrong with setting GL_INVALID_OPERATION?
GL_INVALID_OPERATION: The specified operation is not allowed in the
current state. The offending command is ignored,
and has no other side effect than to set the
error flag.
This sounds to me like exactly what we want. I'm not crazy about allowing
the implementation to simply crash, as anything that "leads to GL interruption
or termination" is explicitly disallowed by the spec.
> Here's a new version of the spec revised to remove GLU queries and
> adding the following two issues:
>
> 122a128,137
> > * Can core GL 1.0 / GLX 1.0 features be queried?
> >
> > TBD. Adds consistency at the cost of a much larger lookup
> > mechanism.
Actually, I think the lookup mechanism would be dramatically simplified,
since it wouldn't have to be special cased to not return a subset.
> > * Should the pointers returned be required to be equal to the
> > addresses of the corresponding static functions (if they exist?)
> >
> > TBD. This may be unreasonable to mandate.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
