Compound IF Can Corrupt User-Defined Type Argument in SUB (84187)

SYMPTOMS

Using a compound IF statement in a subprogram to test floating point elements of a passed user-defined type can corrupt those elements. This problem only occurs when running a compiled program. You can work around this error by compiling with the BC /X option, which has the effect of disabling certain optimizations performed by the BC.EXE compiler.

STATUS

Microsoft has confirmed this to be a bug in Microsoft QuickBasic versions 4.0, 4.0b, and 4.5. This problem was corrected in Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1 (fixlist7.00, fixlist7.10).

Steps to Reproduce Problem

Launch the QB.EXE environment and enter the following program:

DECLARE SUB TestSub(mytype AS ANY)
TYPE maintype
        a as SINGLE  'These could also be of type DOUBLE
        b as SINGLE  'and the same error would occur.
        c as SINGLE
END TYPE

DIM main AS maintype
CLS

main.a = 1.23
main.b = 4.56
main.c = 7.89

CALL TestSub (main)

Sub TestSub (mytype as maintype)

        IF main.a <> 0 AND main.b <> 0 AND main.c <> 0 THEN
                PRINT main.a, main.b, main.c
        END IF

END SUB

This program will execute correctly in the QB.EXE environment, but when compiled, it produces an erroneous value for main.c when printed out in TestSub. As noted above, this can be avoided by compiling with the BC /X compile option.