Q58732: QB 4.50 Parameter Passed to Separate Module Shows as Garbage

Article: Q58732
Product(s): See article
Version(s): 4.50
Operating System(s): MS-DOS
Keyword(s): ENDUSER | SR# S900210-1 buglist4.50 | mspl13_basic
Last Modified: 1-MAR-1990

A QuickBASIC 4.50 program that calls a subprogram located in a
separate module (such as in a library or Quick library) can have a
parameter's contents become corrupt under the specific circumstances
described further below. After the parameter has been corrupted,
PRINTing that parameter may display "garbage" instead of the correct
results.

Microsoft has confirmed this to be a problem in Microsoft QuickBASIC
Version 4.50. We are researching this problem and will post new
information here as it becomes available.

This problem does NOT occur in earlier versions of QuickBASIC, in
Microsoft BASIC Compiler Versions 6.00 or 6.00b for MS-DOS and MS
OS/2, or in Microsoft BASIC Professional Development System (PDS)
Version 7.00 for MS-DOS and MS OS/2.

The conditions under which parameters may become corrupt are as
follows:

1. Variables are passed using argument and parameter lists to a
   subprogram located in a separate module (a linked .OBJ, a library,
   or a Quick library). (This problem does not occur if variables are
   passed through a COMMON SHARED statement.)

2. The second argument passed is of type SINGLE, DOUBLE, or INTEGER.
   (This problem does not occur with long integers.)

3. In the subprogram, the variable in the first position of the
   parameter list is multiplied by the variable in the second
   position, giving the result to a third variable such as a third
   parameter or a variable local to the subroutine. The problem
   does not occur if the order of multiplication is switched.

4. If all of the above conditions are met, the variable that is
   defined in the second position of the parameter list shows garbage
   when PRINTed even though no changes were made to this variable.
   All other variables are displayed correctly.

The following program exhibits the problem:

Main Level Code
---------------

   x = 5
   y = 6
   Print "Before Call "; x, y, z
   CALL Garbage(x, y, z)
   PRINT "After Call "; x, y, z   '--Correct values are displayed
                                  '  after exiting the sub

Separate Module (.OBJ, Library, or Quick Library) Code
------------------------------------------------------

   SUB Garbage (x, y, z)
     PRINT "In sub, before multiplying "; x, y, z  '--Correct values
                                                   '  are displayed
     z = x * y                   '--Change this line to z = y * x
                                 '  and program will work correctly
     PRINT "In sub, after multiplying  "; x, y, z  '--y displays garbage
   END SUB

Workarounds
-----------

One workaround to the problem is to assign the variable located in the
second position of the parameter list to a temporary variable and work
with that temporary variable. At the end of the procedure, assign the
parameter variable the value of the temporary variable. For example,
the procedure in the library or Quick library would look like the
following:

   SUB Garbage (x, y, z)
      ytemp = y
      z = x * ytemp
      y = ytemp
      PRINT "Printing ytemp "; ytemp
      PRINT "Printing y     "; y
  END SUB

Another workaround is to pass variables through a COMMON SHARED
statement instead of a parameter list.

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1986-2002.