Robert Purves wrote:

> >Trying to figure out what Osamu's problem was, (I was just able to see that
> >there was most certainly a bug in the Runtime), I have found another strange
> >thing with the PtrAndHand call used in the FN AppendPString.
> >This is not how Osamu originally wrote it, but this form works OK in PPC but
> >not in 68K:
> >
> >LOCAL FN AppendPString(dstHandle&, @srcStringPtr)
> >  LONG IF dstHandle&
> <snip>
>
> >To make it work in 68K you need to specify in the formal parameter list that
> >srcStringPtr is a pointer to a string like this:
> >
> >LOCAL FN AppendPString(dstHandle&, @srcStringPtr AS PTR TO STR255)
> >  LONG IF dstHandle&
> <snip>
> >
> >I don't understand why it is required in 68K and not in PPC.
> >Alain
>
> The variable srcStringPtr is supposed to contain the address (4 bytes) of a
> string.
> In your first form
> LOCAL FN AppendPString(dstHandle&, @srcStringPtr)
> srcStringPtr is untyped and therefore by default is a 2-byte integer.
> In 68K it is passed in 2 bytes on the stack and cannot work as a 4-byte
> address.
> In PPC (with register vars on) it is passed as a register variable. FB^3
> makes little distinction between 1-, 2- and 4-byte variables when they are
> in a register, and so the correct 4-byte address survives intact, more by
> luck than by good programming.
>
> Better surely to define both parameters explicitly as follows:
>
> LOCAL FN AppendPString( dstHandle as handle, @srcStringPtr as ptr )
>

Thanks Robert,

I was wrongly assuming that FB knew I wanted to use the address of the variable
with the @ symbol.

Cheers

Alain