Re: Program bugs and Game bugs

[Rubywand <rubywand@swbell.net>]

DEVEN ATKINSON writes ...
> 
> In article <34F2C0E5.FAD56C7D@swbell.net>,
> Rubywand  <rubywand@swbell.net> wrote:
> >DEVEN ATKINSON writes ...
>
> >
> To fit your addition to my original analogy..  The OS has the flashing
> sign but it puts it away from the pothole thus not protecting it. ....

     Granted, Apple did not slap a big yellow "Pelegro" sticker on the
ToolBox Reference page describing SetTSPtr; but, they might as well
have. It is amply clear that SetTSPtr is not intended to be CALLed from
an application and that doing so is risky. To quote:

>>
Note: This call is normally used only if you are writing your own tool
set. See
Appendix A, "Writing Your Own Tool Set," for more information.
<<

     This note is followed by discouraging references to the Memory
Manager's moving around and resizing tables for Tool Pointers and Work
Areas, etc., etc..



> ....  It
> is standard practice to fix the problem at its source.

     Of course. However, until the problem is fixed, it is best to avoid
having the problem crash your programs.



> Kludges and
> other workarounds cause more problems than they are worth.

     If by "kludge" and "workaround" you mean doing something other than
making a system CALL which bombs your program, then, clearly, a "kludge"
that avoids the bomb is preferable.



> It is not
> wrong to 'decide' that hte OS is  needs fixed.

     Fixing the OS is a fine idea. I vote "Yes".



> ....
> Programmers who follow documented program calls expect them to function
> correctly. ....

     In general, this is true. But, then, since a programmer may not be
entirely sure what "correctly" is and since, as in the case of the IIgs
OS, one can not always be certain that a bug will not be triggered, it
is best to test the program thoroughly after making any change.



Rubywand