Right Shift

[CrashRoX]

Here's some confusion for you...

<?PHP
$x = (4653896912 >> 13);
echo $x;
?>

I ran that on two different servers.

Server A gave me: 43814
Server B gave me: 568102

I have been hacking away and researching this for hours. I am
completely clueless. Any suggestions or workarounds? Thanks in advance.

[Oli Filth]

Re: Right Shift

CrashRoX said the following on 15/03/2006 10:32:[color=blue]
> Here's some confusion for you...
>
> <?PHP
> $x = (4653896912 >> 13);
> echo $x;
> ?>
>
> I ran that on two different servers.
>
> Server A gave me: 43814
> Server B gave me: 568102
>
> I have been hacking away and researching this for hours. I am
> completely clueless. Any suggestions or workarounds? Thanks in advance.
>[/color]

4653896912 is bigger than can be represented as a signed-int on a 32-bit
platform, so gets truncated to 358929616. And (358929616 >> 13) == 43814.

However, 4653896912 can be represented as a signed-int on a 64-bit
platform, giving the "correct" answer of 568102.


[NOTE: I haven't checked this to see if it's right though...]

--
Oli

[CrashRoX]

Re: Right Shift

I just figured out that server A is a 32 bit machine and server B is
64. How can I account for this?

[CrashRoX]

Re: Right Shift

Im actually looking for the answer as 43814. Is there no "workaround "
or solution to force a 64 bit machine to generate the same answer?

[Oli Filth]

Re: Right Shift

CrashRoX said the following on 15/03/2006 10:48:[color=blue]
> Im actually looking for the answer as 43814. Is there no "workaround "
> or solution to force a 64 bit machine to generate the same answer?
>[/color]

Why are you looking for this to be the answer? In some senses,
(4653896912 >> 13) is meaningless on a 32-bit machine.

However, I guess you could do:

$x = 4653896912;
$y = $x & 0xFFFFFFFF;
$z = $y >> 13;

I can't confirm that this will work though, as I don't have access to
64-bit PHP...

--
Oli

[Jerry Stuckle]

Re: Right Shift

CrashRoX wrote:[color=blue]
> I just figured out that server A is a 32 bit machine and server B is
> 64. How can I account for this?
>[/color]

Don't count on values larger than the maximum integer size! It just
creates more bugs.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[CrashRoX]

Re: Right Shift

I know the actual results are meaningless for a 32-bit system. Im
dealing with an application that was designed on a 32bit system and is
being ported to 64. Unfortunately the system was designed to use
results generated from the 32-bit system, regardless if it has meaning.
Oli Filth's suggestion seems to be working. Hopefully it will hold up.

Thank you.

[CrashRoX]

Re: Right Shift

The right "workaround " seems to be doing the job. Will this work the
same way going left?

$x = $a;
$y = $x & 0xFFFFFFFF;
$z = $y << $b;

return $z;

[CrashRoX]

Re: Right Shift

I believe I narrowed down my bug to ZOR. The right and left shifts
seems to be working just fine with the workaround suggested. Any
suggestions for a ZOR workaround?

[CrashRoX]

Re: Right Shift

I believe I narrowed down my bug to XOR. The right and left shifts
seems to be working just fine with the workaround suggested. Any
suggestions for a XOR workaround?

[CrashRoX]

Re: Right Shift

I believe I narrowed down my bug to XOR. The right and left shifts
seems to be working just fine with the workaround suggested.

$b ^= $c

is giving me different results on the 32bit machine and the 64. Im
looking to get the same 32bit answer on the 64bit machine. Any
suggestions for another workaround?