I don't care what are the internal conversions that Ming has made. x = 0xffffffff; x = x << 16; trace(x); // should output -1, no mater on a 32bit or 64bit system. shouldn't it?
So if Ming(cvs version) give us a different result, it must be a Ming compiler error. BTW, x = 4.29497e+09; x = x << 16; trace(x); //of course the output won't be -1. it is 177209344 as I tested. > This reduces to the double 4.29497e+09 being converted to -1 by the pp > but NOT by gnash. Em..., What do you mean? On 8/7/07, strk <[EMAIL PROTECTED]> wrote: > I tracked the difference between the two movies down to this: > > My local version: > [000] Constant: 75 "x" > [001] Double: 4.29497e+09 > > The version on gnashdev: > [000] Constant: 75 "x" > [001] Integer: -1 > > Basically, a=0xffffffff becomes: > > [001] Integer: -1 > > or > > [001] Double: 4.29497e+09 > > Depending on whether automatic conversion to double is implemented in Ming we > get > two different pushes. Still, it seems the properietary player returns -65536 > when shifting both numbers 16 bits left. > > This reduces to the double 4.29497e+09 being converted to -1 by the pp > but NOT by gnash. > > --strk; > _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
