[Coco] Fw: A bug in Basic09/RunB

[Wayne Campbell]

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
>
>