Hi Tim,
in a message of 23.Nov. you wrote ref "And yet another bug!":
TH> I have a simple numerical data type in a SUB. I set it to, 
TH> say, '5' and simply attempt to PRINT it. I get a run-time 
TH> overflow at the print command!
TH> Of course it doesn't do this consistently. just *below* the 
TH> PRINT command I have a FOR/NEXT with STEP -1. If I change the 
TH> STEP to '1' I get no error.
In all such dubious cases I try to use Borland's TDMAP together 
with the Turbo-Debugger Vs 3.x, (Vs 4.x does not cooperate with 
TDMAP!). This allowes to debug a PB-.EXE on the ASM level and to 
invade with the debugger into the run time libraries. If you 
become a routinier in doing so, you can detect interesting 
relations.
Here a description of the method:
-=-=-=-=-=-=-=-=-=-=-=-=-=-= cut =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Symbolic debugging of *.EXE - files with the Turbo-Debugger
-----------------------------------------------------------------
    Borlands TurboDebugger TD.EXE (is contained e.g. in Turbo C) is much more
    intelligent than the debugging features, built in PB.EXE or PBD.EXE!
    TD.EXE (together with a MAP file) can show the following AT THE SAME 
TIME: 
     one line: "PB line number" + "Basic Statement" (Highlevel)
        then several lines:  corresponding ASM-Code (Lowlevel)
      etc.
    With this method, the correct names of the PB variables and the PB 
    subroutines are put into the disassembled ASM lines (as far as they are
    contained in the PB MAP file). This allows a
       SYMBOLIC debugging, either Highlevel or Lowlevel !!
                              of PowerBasic programs
    E.g. to answer the following question
        "i% = i%+1     or   INCR i%     -     what is faster"
    one has to proceed like this:
    a) Write the testprogram TD_TEST.BAS in the IDE:
       '-------------------------  cut  ------------
       'TD_TEST - Demo: PowerBasic .EXE    1
       '  files with the Turbo debugger    2
       '                                   2
       $LIB ALL OFF                       '4
       '                                   5
       i% = 0                             '6
       i% = i% + 1                        '7
       INCR i%                            '8
       PRINT i%                           '9
       '-------------------------  cut  ------------
       then compile it to an .EXE file together with a MAP file, then exit
       to the DOS prompt. You have now TD_TEST.EXE and
       '-------------------------  cut  -----------------------------
       TD_TEST.MAP:
       Start  Stop   Length Name
       00000H 00000H 00000H LSEG1
       00000H 0382FH 03830H LSEG2
       03830H 07B2FH 04300H LSEG3
       07B30H 07BAFH 00080H LSEG4
       07BB0H 07CCFH 00120H PowerBasicSeg01
       07CD0H 07CD0H 00000H VSEG 
       07CD0H 07CDFH 00010H RSEG 
       07CE0H 07CE0H 00000H SSEG 
       07CE0H 08FEFH 01310H DATA 
       Address         Publics
       07CE:12F0       I
       0000:0020       SETONMEMPACK
       usw.
       0000:FE32       FIARQQ
       Line numbers for (C:\PB3\TD_TEST.BAS) segment PowerBasicSeg01
       6 07BB:00EC     7 07BB:00F2     8 07BB:00FD     9 07BB:0102
       11 07BB:0111
       '-------------------------  cut  -----------------------------
    b) Then the utility TDMAP.EXE (belonging to the turbodebugger TD.EXE)
       has to be invoked:
                TDMAP TD_TEST
       This utility prepares the informations contained in TD_TEST.MAP in a
       way (and adds them to the end of TD_TEST.EXE, thus this files becomes 
a 
       bit longer), that the debugger now knows the addresses of the Basic 
       sourcecode lines and all public names and their addresses of the Basic 
       program.
       Screen output of TDMAP:
             Reading segments
             Reading publics by name
             Reading publics by address
             Reading line numbers
             Correlating line numbers
             Writing debug output
    c) The debugger is now called:
             TD -l TD_TEST   (the switch "-l" means: ASM presentation)
       the start value of the code segment is read as e.g. "CS = 51B0"
    d) A breakpoint is set to the beginning of line 6 (i% = 0):
           debugger segment (see c)                  51B0
           plus address of line 6 (from the MAP)    +07BB:00EC
                                                    ----------
           results into breakpoint address:          596B:00EC
    e) After ordering the debugger to "start the program" (F9), it runs to
       the breakpoint, then stops and the screen shows somewhat similar to:
       '-------------------------  cut  -----------------------------
       #powerbasicseg01#6:    i% = 0                        = line 6
         cs:00EC C706F0120000    mov word ptr [12F0],0000
       #powerbasicseg01#7:    i% = i% + 1                   = line 7
         cs:00F2 B80100          mov ax,0001
         cs:00F5 0306F012        add ax,[12F0]
         cs:00F9 CE              into
         cs:00FA A3F012          mov [12F0],ax
       #powerbasicseg01#8:    INCR i%                       = line 8
         cs:00FD FF06F012        inc word ptr [12F0]
         cs:0101 CE              into
       usw.
       '-------------------------  cut  -----------------------------
    (and this proves: "INCR i%" is shorter and faster than "i% = i% + 1")
    By the way: With the CV (CodeView) debugger of Microsoft this performance 
    seems not to be possible.
-=-=-=-=-=-=-=-=-=-=-=-=-=-= cut =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
By single stepping with the Turbodebugger on ASM-Level, starting
at your PRINT statement, you may get an answer to your question.
Regards
            Andras
--- CrossPoint v3.11 R
---------------