[Coco] DEFUSRn parameters vs. Color Extended BASIC manual

[Arthur Flexser]

I've always found INTCNV and GIVABF to be more trouble to use than
they were worth.

If I need to give an ML routine access to a string defined in Basic, I
just put the string at a safe location where the ML can find it.  I do
this by poking the desired address into the 3rd and 4th(?)  bytes of
the string descriptor, whose location is given by the VARPTR function.
The length of the string gets poked into the first byte of the
descriptor.

Art


On Mon, Apr 22, 2019 at 1:27 PM Joel Rees <joel.rees at gmail.com> wrote:
>
> Thanks, Arthur and William, for the confirmation about the conversion
> routines INTCNV and GIVABF.
>
> I'm playing with the USRn interface and I think it is clear that the Color
> Extended BASIC manual, in addition to containing typos, contains errors in
> the descriptions.
>
> When passing a string in, if you pass it with VARPTR giving the address, if
> the return value is stored in a string varable, it says TM error (type
> mismatch). But if you store it in a numeric, it doesn't complain. But the
> value in X is not the address of the string.
>
> If you pass it without VARPTR, if the return value is stored in a numeric,
> it gives type mismatch. But if you store it in a string, it doesn't
> complain, and the address in X is the address of the string, as described.
>
> Since the VARPTR is an integer, I'm guessing that the address passed that
> way gets passed as a numeric, requiring conversion by INTCNV to recover,
> which would require the BASIC interpreter to do less magic interpretation
> of user intent. I suppose I should test that after I get some sleep.
>
> Typical Microsoft misspecification, really.
>
> And it leaves me inclined to pass integers as hexadecimal numbers stored to
> strings, rather than depend on INTCNV and GIVABF.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco