> I suppose its a matter of style. I would query for extension support
> before querying the entry points themselves. There's no reason it can't
be
> done in the other order, besides aesthetics.
>
Beyond aesthetics I'm concerned on the impact context dependant procs on
driver stability. What happens if I invoke a context dependant proc while a
dissimilar context is current? The extension is probably going to look for
and expect to be able to alter some extension specific state in the device
dependant section of the context. Clearly we could be reading or writing
bad addresses, with all the attendant problems. Do we write out of bounds?
Do we look for a pointer in some location where we find color index instead?
Do we overwrite some critical state in the currently bound context ( the
length of the pending command token queue for instance, the address of some
vital gfx card register, I'm sure you can think of worst case scenario
values to be corrupted in YOUR gl contexts)? So how do we fix this? We
check for context validity in the extension proc, right? Well, we've just
made the proc context-independant... because once you check you've paid the
context independence entry price and you might as well see if there's a
valid function to call... though some would argue it's better to NOOP a set
error. In any case context dependence has saved you exactly nothing.
Thoughts?
Best Regards,
John M. Zulauf
Santa Barbara, CA
