(Probably) New bug found in HP-71B (2CDCC and possibly others)

[Valentin Albillo]

      
Hi, all:

I've found what I believe to be a never-before-reported bug present in the most recent version of the HP-71B ROMs, namely the 2CDCC one. I found it while using an Emu71 instance with these installed ROM versions:

      >VER$
                  HP71:2CDCC MATH:1A JPC:F01 HPIL:1B STRU:A RCPY:E

The problem can be reproduced by following this minimal example:

(Note: To guarantee correct reproduction first execute END ALL and DESTROY ALL and enter these code snippets on an empty worfile. You might also want to execute DELAY 0.5 to see the output before it scrolls up out of view when running the 2nd and 3rd code snippets.

Caveat: Also, after finding and investigating this bug I've not experienced any problems like corrupted memory, corrupted file chain or system unstability so I deem it perfectly safe for you to run the following code snippets without experiencing any problems but, as usual, no guarantees).

1) Correct functionality (no user-defined function):

This code snippet displays the square root of integers in a FOR-NEXT loop and tries to catch the error when the integers become negative, in which case the error is trapped and displayed and the loop continues with the next integer till the loop is completed and the program outputs "Done" and terminates:

10 ON ERROR GOTO 40 @ FOR X=3 TO -2 STEP -1 @ DISP "X=";X;
20 Y=SQR(X) @ DISP ", Sqrt(";X;")=";Y
30 NEXT X @ DISP "Done" @ END
40 DISP ", Error";ERRN;"in line";ERRL @ GOTO 30

>RUN

X= 3 , Sqrt( 3 )= 1.73205080757
X= 2 , Sqrt( 2 )= 1.41421356237
X= 1 , Sqrt( 1 )= 1
X= 0 , Sqrt( 0 )= 0
X=-1 , Error 10 in line 20
X=-2 , Error 10 in line 20
Done

This is the expected correct behaviour. Note that when X=-1 the error is trapped and displayed instead of the numeric square root and the loop's execution continues with the next integer, namely X=-2, where the error is again trapped and displayed, and as there's no next element the loop ends and the program terminates normally. The reported error is of course:

      >MSG$(10)
                  SQR(neg)

2) Incorrect functionality (a single-statement UDF):

Now we replace the Y=SQR(X) at line 20 with a call to a single-statement user-defined function, i.e.: Y=FNF(X), which we define at line 1. The changed code is:

1 DEF FNF(N)=SQR(N)
10 ON ERROR GOTO 40 @ FOR X=3 TO -2 STEP -1 @ DISP "X=";X;
20 Y=FNF(X) @ DISP ", Sqrt(";X;")=";Y
30 NEXT X @ DISP "Done" @ END
40 DISP ", Error";ERRN;"in line";ERRL @ GOTO 30

>RUN

X= 3 , Sqrt( 3 )= 1.73205080757
X= 2 , Sqrt( 2 )= 1.41421356237
X= 1 , Sqrt( 1 )= 1
X= 0 , Sqrt( 0 )= 0
X=-1 , Error 10 in line 1
, Error 43 in line 30
, Error 43 in line 30
, Error 43 in line 30
... (continues indefinitely) ...

This is incorrect behaviour. When X=-1, the error is trapped and displayed as before, reported at line 1 (the UDF) when it tries to compute the square root of its argument, -1. So far so good.

But then, when the NEXT X at line 30 gets executed, a new error gets trapped and reported, and the NEXT X is executed again with the same result so the program never stops but is stuck into an infinite loop.

The first error is the same we saw before, namely:

      >MSG$(10)
                  SQR(neg)

But the new, wholly unexpected error is:

      >MSG$(43)
                  NEXT w/o FOR

So it seems that when the error occurs in the UDF, despite getting traped it nevertheless manages to disrupt the FOR-NEXT loop which gets unduly terminated or corrupted so that NEXT X fails, unlike what happened when we used SQR(X) instead of FNF(X).

This incorrect behaviour also happens when using a multi-statement user-defined function:

1 DEF FNF(N) @ FNF=SQR(N) @ END DEF
10 ON ERROR GOTO 40 @ FOR X=3 TO -2 STEP -1 @ DISP "X=";X;
20 Y=FNF(X) @ DISP ", Sqrt(";X;")=";Y
30 NEXT X @ DISP "Done" @ END
40 DISP ", Error";ERRN;"in line";ERRL @ GOTO 30

>RUN

X= 3 , Sqrt( 3 )= 1.73205080757
X= 2 , Sqrt( 2 )= 1.41421356237
X= 1 , Sqrt( 1 )= 1
X= 0 , Sqrt( 0 )= 0
X=-1 , Error 10 in line 1
, Error 43 in line 30
, Error 43 in line 30
, Error 43 in line 30
... (continues indefinitely).


To wit: simply replacing Y=SQR(X) with Y=FNF(X) and trying to catch the "SQR(neg)" error within a FOR-NEXT loop causes the loop to be terminated early (and/or corrupted) and the program to get stuck into an infinite loop.

I've been looking at the documents J-F Garnier kindly published and mentioned in his Emu71 web site, namely "HP-71B Known Bugs February 6, 1985" (34 pages) and this particular bug doesn't seem to be mentioned there. The closest I've found there reads like this:

      "1072-8 (Rank 4) Outer FOR...NEXT loop is corrupted when inner FOR statement errors
       at execution. (Only a problem is you do keyboard GOTO after the FOR
       statement error)"

As you may see there's no mention of UDFs at all in bug 1072-8 and the description and commentary doesn't seem to apply to my minimal example so I'm pretty sure my newly found bug is different from the old 1072-8 reported there.

If this is indeed the case I think that it would be proper to include it in the list of known HP-71B bugs (it's probably present in all ROM versions up to and including 2CDCC) as well as any relevant comments (does it corrupt other things as well ?) and any workarounds which might be concocted.

Regards.
V.