----- Original Message -----
From: Michael I. Gold <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 15, 1999 10:34 AM
Subject: Re: [oglbase-discuss] Updated GL_EXT_get_proc_address spec
> 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.
then in a way are you saying that the proc functions like the context
independent proc would in this case? (grin)
>
> 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.
But one also should not design an interface such that it promotes minor
errors to core dumps. Would you want a call to glIndex to crash an
application if the current context is for an RGB window? This is exactly
analogous -- the application making an OpenGL function call incorrectly in a
context not supporting that capability. If we hadn't gotten the proc from
getProc but from the header file and linked with it directly we wouldn't
crash, right? Your attitude seems a trifle callous -- especially since in
using a dispatch table you could as easily (and with no additional overhead)
avoided the whole problem by implementing the getProc in a
context-independent way. Its one thing when a program hands a driver a NULL
pointer, or forgets an initialization step, this sort of thing is fairly
obvious and easily tracked down as it will fail at the actual bug or at the
first real graphics call.
What we're talking here about is a data corruption bug which could lead to a
crash very far removed from the actual erroneous call. These are among the
hardest bugs for applications developers to find. I tracked a hard to find
and reproduce a crash happening from within a windows dialogbox. The
arguments to the dialog box were perfect, the callbacks flawless. The
fault? Some NLS support settings in some obscure corner were being done
incorrectly and thus apparently corrupting the window internal font handling
or who knows what. This bug accounted for man-weeks (plural) of effort.
It's one thing to slow good applications by always checking for NULL
(nothing I'd advocate, except in a debug library...), clearly that's too
expensive. However it's another to structure an extension in a way that is
known to be prone to this sort of difficult error. Ease of use matters,
even in graphics languages, as you obviously know already or you would
writing PHIGS extensions instead of OpenGL ones (friendly grin).
>
> -- Michael
>
Respectfully disagreeing, (and down off my soap box)
John
