Bugs

[David Burgun]

On 10 Apr 2006, at 02:13, Francis Nugent Dixon wrote:

> Hi from Paris,
>
> Many - many years ago, I came across a simple program
> written to print out paychecks (in 1401 AutoCoder, for anybody
> who wants to know). The input to the program was .... you've
> guessed it  ...  punched cards, containing basic information,
> such as :
>
> 1 - a code (1 for man, 2 for woman),
> 2 - Employee code number (six digits),
> 3 - Employee name (25 characters)
> 4 - Number of hours worked in the week (3 digits)
>
> The program needed the sex code, because the hourly
> rate for a woman was less than that of a man (nothing has
> changed, even 40 years later !).
>
> Tests were conclusive, the programmer eliminated invalid
> employee codes, and hours worked in excess of 45, etc, etc.
> So the programmer did a run on REAL data for the current month.
>
> The program blew 30 seconds later ...... but only because the
> employee was ..... neither a man or a woman ......
>
> From then on, programmers were instructed to FIRST test their
> programs with blank cards .......
>

Actually this is a good example for another reason. If you equate the  
"blank" card to the "empty" concept in TranScript, you will see that  
TranScript actually makes things a little worse in some cases here.  
By this I mean, you can get away with passing empty to RevRev  
functions etc. and it will accept them, even when they don't make  
sense. For instance:

if there is a folder myFolder then
     new folder myFolder
end if

the part that handles "there is a folder" allows an empty string to  
be passed to it and fails. On the face of it this is good, it didn't  
identify "empty" as being a valid folder. The problem here is that  
you'd get the same result if "myFolder" contained a valid folder.   
The programmer in this example should have coded:

put empty into myFolder

if myFolder <> empty then
   if there is a folder myFolder then
       new folder myFolder
    end if
  end if

If the "there is a folder" clause generated an Execution Error if it  
were passed empty data, it would help a lot.

There are also a number of cases where "empty" is passed around which  
while they don't cause any problems immediately they cause more  
processing than is necessary to be performed. For instance:

put the keys of myArray into myKeysList
sort lines of myKeysList
repeat with myKeyIndex = 1 to the number of lines in myKeysList
end repeat

Here the extra "sort" operation was performed on an "empty" string,  
is just continued on and hit the repeat statement which then  
immediately failed. Here we are not talking about much overhead, but  
when I traced some code I wrote recently, I found that it was  
traveling down 4 layers of function calls, uselessly passing "empty".  
It was only when I added some code to the bottom layer that was  
"empty" intolerant did I notice the problem. For instance:

Stack;
function StackFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myParam
put CardFunc(myParam ) into myResult

return myResult
end StackFunc


Card:
function CardFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myParam
put GroupFunc(myParam ) into myResult

return myResult
end CardFunc


Group:
function GroupFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myParam
put ControlFunc(myParam ) into myResult

return myResult
end GroupFunc


Control:
function ControlFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myResult

return myResult
end ControlFunc

In this case "empty" was being passed needlessly, but harmlessly down  
4 layers. All is ok, until you add some empty non-tolerant code to  
one of the lower levels. In my case I added it to the Control.

All the Best
Dave