[Coco] A bug in Basic09/RunB

[Lothan]

From: "Wayne Campbell" <asa.rand at yahoo.com>

> The wrong byte is being retrieved. All BYTE variables are expanded into 
> INTEGERs before being processed. In this case,
> the first byte of the integer is being read, not the second. I can never 
> remember which order they are in, so I'm not
> certain which one is LSB and which one is MSB. To be clear:
>
>  +---+---+
>  | 1 | 2 |
>  +---+---+
>
> Byte 1 is being read, when byte 2 should be being read.

Can you look at that again to confirm whether Basic09 is really passing a 
byte as a one-byte value (e.g. $01), a two-byte integer (e.g. $0001), or a 
byte padded to a two-byte parameter slot (e.g. $0100)? The reason I ask is 
because it's quite common for languages to return an integer result of a 
mathematical expression involving byte values so it seems more likely the 
code is mistakenly passing an integer instead of a byte and so the parameter 
slots are filled incorrectly.

As further confirmation, use this quick 'n dirty test program to confirm my 
suspicions:

PROCEDURE Program
    DIM b:BYTE
    b := 9
    b := b + 1
    RUN Test(b)

    b := 9
    RUN Test(b + 1)
END

PROCEDURE Test
    PARAM b:BYTE
    PRINT b
END

If you run Program, you'll see that the output is 10 and 0, This seems to 
confirm that the addition in the first half is likely an integer downcast 
back to a byte, but the addition in the second half is not downcast to a 
byte because Basic09 doesn't have a clue what parameter types are expected 
by the procedure.

> The second bug occurs when you pass multiple variables into a single 
> variable. Based on the fact that it works correctly, under the following 
> conditions, on the first 2 elements of the receiving array, it should be 
> working correctly for all of the parameters needed to equal its size. The 
> test procedure passed 3 INTEGER variables into 1 3-element INTEGER array.
>
> PROCEDURE testParams
> DIM a,b,c:INTEGER
> a:=1 \b:=2 \c:=3
> RUN recPars(a,b,c)
> END
>
> PROCEDURE recPars
> DIM cntr:INTEGER
> PARAM d(3):INTEGER
>
> FOR cntr:=1 TO 3
> PRINT d(cntr)
> NEXT cntr
> END
>
> Results:
>
> 1
> 2
> 56 (Parameter Error)
>
> In addition, I added a fourth parameter, a second reference to a, and a 
> 4th element to d. The error occurred in the same position in the array as 
> before. Therefore, the accumulator that is supposed to count the parameter 
> sizes is exiting before the final parameters are being processed.

Verify the differences between passing three integer values (e.g. a, b, and 
c) versus passing an integer array containing three elements. I suspect 
you'll find a difference there as well.