Re: Re[2]: [Gnash-commit] gnash/testsuite/actionscript.all ops.as

[zou lunkai]

On 8/7/07, Udo Giacomozzi <address@hidden> wrote:
> Hello zou,
>
> Tuesday, August 7, 2007, 3:10:51 AM, you wrote:
> zl> x = 0xffffffff;
> zl> x = x << 16;
> zl> trace(x); // should output -1, no mater on a 32bit or 64bit system.
> zl> shouldn't it?
>
> Why -1 ? You are shifting 16 bits.
>
ops, sorry, it was my mistake.  It should ouput -65536.

(0xffffffff << 16) == ( -1 << 16) == (-65536)

strk found that 0xffffffff was compiled to 4.29497e+09 instead of an
integral  with Ming cvs-head. I uses an older version of Ming, and
after compile 0xffffffff is still an integral. What I intended to mean
was that no matter 0xffffffff being compiled as an integral or a
floating number, the final results should expected to be the
same(-65536). Otherwise, it is a compiler error.

eg.
x = -1;
y = x << 16;
check_equals(y, -65536);

x = 4.294967295e+09;
y = x << 16;
check_equals(y, -65536);

>
> Monday, August 6, 2007, 9:33:53 PM, strk wrote:
> s>Still, it seems the properietary player returns -65536
> s> when shifting both numbers 16 bits left.
>
> Isn't that as expected?
>
> Apparently the PP is using 32 bits signed integer internally when
> shifting.
>
> 0xFFFFFFFF == 2^32-1 for unsigned int == -1 for signed int
>
> 0xFFFFFFFF << 1  == 0xFFFFFFFE == -2
> 0xFFFFFFFF << 2  == 0xFFFFFFFC == -4
> 0xFFFFFFFF << 16 == 0xFFFF0000 == -65536
>
> and so on.
>
> Or am I missing something?
>
yes, you are right. All the results are expected.