Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!BRL.MIL!moss
From: moss@BRL.MIL ("Gary S. Moss", VLD/VMB)
Newsgroups: comp.sys.sgi
Subject: Re:  shademodel
Message-ID: <9002201215.aa18894@VMB.BRL.MIL>
Date: 20 Feb 90 17:15:56 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 37

[Gary Tarolli writes:]
< A stack track should readily identify the offending routine.  As for
< the error messages, here's the reason.  Some of the GL calls, eg. v3f have
< to be called at a very rapid rate (> 1 million per second) to achieve the
< graphics performance the hardware can deliver.  Putting in something as simple
< as an "if" test and worse yet a subroutine call (even if its not taken it will
< make the routine a non-leaf routine which adds lots of code to the procedure's
< entry and exit code), will seriously degrade performance.  Although there are
< many routines that are not performance critical, there are also many many
< things to test for.
Well, I understand that in general you don't want the overhead, but many of
the one time window configuration GL calls, like shademodel() could benefit
from a simple test for a NULL pointer.  Even a failed assertion
(using assert()) would be better than letting a segmentation violation occur.
It may be that the design of the code does not permit this, but that would
be a bad design.

< The code would not be easy to implement - imagine the
< problem of checking for a valid pointer - you should really try to access
< the data while catching segv signals - but what if the user is also catching
< segv signals? etc etc.
Checking a pointer's validity is trivial if pointers are initialized to NULL
*and* reset to NULL once invalidated by winclose() or whatever.  Permitting
an uninitialized variable to be used as a pointer is sloppy coding.

< However, your point is valid - we need better error messages and parameter
< checking.  Rather than add code to the GL, most of us would prefer to build
< an alternate GL that could be used for debugging.  THus the performance of
< the real GL would not be affected.  This debugging GL would only be used
< while debugging.  It could be implemented as a separate library, for those
< who don't use the shared lib, or as a "somehow switchable" part of the 
< shared library that could be activated when desired, or as a DGL filter.
A method that we find useful and easy to maintain is to frame any such code
segments that either impact performance or are inappropriate for production
use (i.e. assert() calls) with #ifdef DEBUG ... #endif compiler directives
so that a debugging version can be easily compiled and made available without
having to maintain separate sources.