On 8/7/07, Udo Giacomozzi <[EMAIL PROTECTED]> 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. _______________________________________________ Gnash-commit mailing list Gnash-commit@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-commit
