Different binary results with different PHP versions

[Skeleton]

I am using Windows XP + PHP 5.1.2 at home for development and using
Linux + PHP 4.4.2 at server side. In my code, I am doing some bitwise
operations. While doing this, I have come accross to different results
from my functions that uses bitwise xor (^) operator. When I digg into
the code, I have tried to print out the binary of a decimal number. The
result was so:

echo decbin(-5817441119);
// Prints 10100101010000001110010010100001 at local (PHP 5.1.2)
// Prints 10000000000000000000000000000000 at server (PHP 4.4.2)

Is this a bug? How can I workaround this problem? Thanks.

[Erwin Moller]

Skeleton wrote:

Hi,

Did you read the Fine Manual?
http://nl2.php.net/manual/en/function.decbin.php

says:
string decbin ( int number )
----------------
Returns a string containing a binary representation of the given number
argument. The largest number that can be converted is 4294967295 in decimal
resulting to a string of 32 1's.
----------------

Your number is bigger, or actually smaller. ;-)

Read the usercontributed notes for details and solutions.

Regards,
Erwin Moller

[Skeleton]

Yes, I have read the manual and notes below the manual. But actually, I
don't need exactly the decbin function. I have used that just to show
something going wrong. My point is the ^ operator. For ex, look at the
following code and its outputs:

echo (1 ^ -5817441119);
// Prints -1522473824 which is true result, at PHP 5.1.2 + Windows
// Prints -2147483647 which is false result, at PHP 4.4.2 + Linux

I also thought that the reason is that the number is too small, but why
PHP 5 calculates correctly? Is there a big difference in number types
between PHP 4 and PHP 5? I don't know if it helps but when I checked
PHP_INT_MAX, it is 2147483647 for both.

[David Haynes]

Skeleton wrote:
> Yes, I have read the manual and notes below the manual. But actually, I
> don't need exactly the decbin function. I have used that just to show
> something going wrong. My point is the ^ operator. For ex, look at the
> following code and its outputs:
>
> echo (1 ^ -5817441119);
> // Prints -1522473824 which is true result, at PHP 5.1.2 + Windows
> // Prints -2147483647 which is false result, at PHP 4.4.2 + Linux
>
> I also thought that the reason is that the number is too small, but why
> PHP 5 calculates correctly? Is there a big difference in number types
> between PHP 4 and PHP 5? I don't know if it helps but when I checked
> PHP_INT_MAX, it is 2147483647 for both.

Be careful of your base assumptions. php 5.1.2 on Linux produces
-2147483647 as well.

-david-

[Skeleton]

My PHP 5.1.2 is on Windows. So the problem is about the Operating
Systems.

[Anonymous]

Skeleton wrote:
>
> My PHP 5.1.2 is on Windows. So the problem is about the Operating
> Systems.
>

No, the problem is that the number is outside of the defined bounds.

*Anything* could be the result, depending how that particular PHP
version, operating system or CPU treats overflowing numbers.

Ex falso quodlibet.

Bye!

[Chung Leong]

No, it's difference is in the compiler. The operation you describe
causes a double-to-long-integer conversion overflow. Gcc probably
throws in a check which sets the value to the integer boundary whereas
MS Visual C just lets it wrap around.

[Skeleton]

So what should I do at this point? I need to make XOR operations with
such big(small) numbers.

[Chung Leong]

What exactly are you trying to do? One possible solution is to perform
the operation on strings instead:

<?

$a = "\x01\x02\x03";
$b = "\xFF\x02\x03";

$c = $a ^ $b;

for($i = 0; $i < strlen($c); $i++) {
printf("%x, ", ord($c[$i]));
}

?>