This is not a problem in my implementation - the returned context-dependent
pointer is a routine which uses a per-thread dispatch table. If none of my
contexts are bound to the current thread, it will dispatch to a nop function.
Even if this were not true, and memory corruption occurred - a bug is a bug
is a bug. I don't think we should design the interface to prevent buggy
programs from crashing.
-- Michael
>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
>
