[Coco] Fw: A bug in Basic09/RunB

[Wayne Campbell]

I changed the test again, and tried putting the 3-int array into 3 ints. The
parameter error occurred on the first int, so I guess this means it doesn't
work the other way, even though it should, going by the fact that the manual
says no type checking is done.

On Mon, Dec 7, 2009 at 2:23 PM, Wayne Campbell <asa.rand at gmail.com> wrote:

> Lothan,
>
> I just ran this test. I changed the a,b, and c integer variables to a(3),
> and all assignments were changed. Then I passed a to recPars. I got a good
> printout. All 3 elements were identified and there. No errors.
>
> Wayne
>
>
> On Mon, Dec 7, 2009 at 2:06 PM, Wayne Campbell <asa.rand at yahoo.com> wrote:
>
>>
>>
>> ----- Forwarded Message ----
>> *From:* Lothan <lothan at newsguy.com>
>> *To:* CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>> *Sent:* Sun, December 6, 2009 10:16:59 PM
>> *Subject:* Re: [Coco] A bug in Basic09/RunB
>>
>> 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.
>>
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>