Richard Pimentel wrote: > > Stephen J Baker wrote: > > Look at it this way: All of the other gl* functions are assumed to > > be "in the present context" - why should glGetFuncAddress be any > > different? > > We can live with this. Just spell this constraint out clearly in the function > spec. To tighten things up even more, will a function pointer be allowed to > ever become invalid within the context that was current when it was queried? I > would say no. What is the behavior of a call to a function pointer after its > context is deleted? Crash the app. I hope since this would be a very bad bug. > It is sort of analoguos to dereferencing stale pointers. As I see it, the problem is exactly the opposite. I.e. it would be a very subtle bug for an application to get a function pointer in context A, then call it in context B. Must we now require that every OpenGL function whose pointer is returned by "GetProcAddress()" check to ensure that it's being called while the same context from which it was obtained is current? Wuf, I hope not. That would be an awful performance penalty. If we don't require this behavior, we have to say that the behavior in this situation is undefined. The function can't set a glError if it hasn't checked to see if it's in its own context, so it would just do its normal thing, assuming that it owns the current context. It might crash the driver if the developer is lucky, or worse, it might just silently change some unintended context state that won't be noticed until 5 frames later (or until the app user turns on some currently unused feature that relies on said state). Yuck... This is a potential nightmare for app developers. Cheers!
begin:vcard n:Johnson;Brett x-mozilla-html:FALSE org:Hewlett-Packard;Worstation Systems Lab adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:WSL Turtle Master fn:Brett Johnson end:vcard
