Xor bug in all PHP versions

[DigDug]

I get two different results in doing a Xor on a large signed double
between linux servers.
working system is kernel 2.4 . bad results server is kernel 2.6.

PHP version does not matter. I compile PHP from 4.2.2 to latest.

test code:
<?PHP echo -4738698913 ^ 43814; ?>

results:

Good result from 2.4 kernel system is -443704711
Bad result from 2.6 kernel systems(tried 5 different systems) is
-2147439834

BUG in PHP or kernel?

[Andy Hassall]

On 18 Jan 2006 13:32:23 -0800, "DigDug" <do*******@hotmail.com> wrote:

I get two different results in doing a Xor on a large signed double
between linux servers.
working system is kernel 2.4 . bad results server is kernel 2.6.

PHP version does not matter. I compile PHP from 4.2.2 to latest.

test code:
<?PHP echo -4738698913 ^ 43814; ?>

results:

Good result from 2.4 kernel system is -443704711
Bad result from 2.6 kernel systems(tried 5 different systems) is
-2147439834

BUG in PHP or kernel?

32 or 64 bit architecture?

Have you seen the related user notes on
http://www.php.net/manual/en/languag...rs.bitwise.php ? (Not all apply to
XOR but there are several in there that may interest you).

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Pedro Graca]

DigDug wrote:

I get two different results in doing a Xor on a large signed double
between linux servers.
The ^ operator takes two integers, all bitwise operator do.
working system is kernel 2.4 . bad results server is kernel 2.6.

PHP version does not matter. I compile PHP from 4.2.2 to latest.

test code:
<?PHP echo -4738698913 ^ 43814; ?>
<?php if (PHP_VERSION>='4.4.0') echo PHP_INT_MAX; ?>

<?php echo var_dump(-4738698913); ?>

<?php echo -4738698913 | 0; ?>

<?php echo var_dump(-4738698913 | 0); ?>
results:

Good result from 2.4 kernel system is -443704711
64-bit machine?
Bad result from 2.6 kernel systems(tried 5 different systems) is
-2147439834
32-bit machine?
BUG in PHP or kernel?

Neither, I think.

--
If you're posting through Google read <http://cfaj.freeshell.org/google>

[Chung Leong]

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?

[Tim Roberts]

"Chung Leong" <ch***********@hotmail.com> wrote:

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?

First, answer this question: how can you squeeze -4,738,698,913 into a
32-bit variable?

4,738,698,913 would be 1_1A72_CEA1 in hex, but that needs 33 bits. If you
truncate that to 32 bits, you get 1A72_CEA1. Xor that with 43,814, which
is AB26 in hex, and you get 1A72_6587, which just happens to be
443,704,711.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Oli Filth]

Tim Roberts said the following on 20/01/2006 06:59:

"Chung Leong" <ch***********@hotmail.com> wrote:

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?

First, answer this question: how can you squeeze -4,738,698,913 into a
32-bit variable?

4,738,698,913 would be 1_1A72_CEA1 in hex, but that needs 33 bits. If you
truncate that to 32 bits, you get 1A72_CEA1. Xor that with 43,814, which
is AB26 in hex, and you get 1A72_6587, which just happens to be
443,704,711.

But that's assuming that PHP performs XOR on the absolute values of the
operands, and then negates appropriately. i.e.:

(-4,738,698,913 ^ 43,814) == -(4,738,698,913 ^ 43,814)

which isn't the case, at least not always. e.g.:

echo (3 ^ 7) . "\n";
echo (-3 ^ 7) . "\n";

i.e. doing XOR directly on the 2's-complement representations of the
operands.

As a side-note:
I don't like the fact that even basic PHP code isn't portable between
platforms, i.e. it doesn't abstract away differences in platform bitwise
implementations of signed values.
--
Oli

[Jerry Stuckle]

Oli Filth wrote:

Tim Roberts said the following on 20/01/2006 06:59:

"Chung Leong" <ch***********@hotmail.com> wrote:

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?

First, answer this question: how can you squeeze -4,738,698,913 into a
32-bit variable?

4,738,698,913 would be 1_1A72_CEA1 in hex, but that needs 33 bits. If
you
truncate that to 32 bits, you get 1A72_CEA1. Xor that with 43,814, which
is AB26 in hex, and you get 1A72_6587, which just happens to be
443,704,711.

But that's assuming that PHP performs XOR on the absolute values of the
operands, and then negates appropriately. i.e.:

(-4,738,698,913 ^ 43,814) == -(4,738,698,913 ^ 43,814)

which isn't the case, at least not always. e.g.:

echo (3 ^ 7) . "\n";
echo (-3 ^ 7) . "\n";

i.e. doing XOR directly on the 2's-complement representations of the
operands.

As a side-note:
I don't like the fact that even basic PHP code isn't portable between
platforms, i.e. it doesn't abstract away differences in platform bitwise
implementations of signed values.

No, Tim is correct. PHP CAN'T do an XOR on -4,738,698,913 on a 32 bit
system. The value doesn't fit into 32 bits!

It has nothing to do with the absolute value. In fact, in bit
operations other than right shift, there is no "absolute value". There
are just bits.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Oli Filth]

Jerry Stuckle said the following on 20/01/2006 13:22:

Oli Filth wrote:

Tim Roberts said the following on 20/01/2006 06:59:

"Chung Leong" <ch***********@hotmail.com> wrote:

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?
First, answer this question: how can you squeeze -4,738,698,913 into a
32-bit variable?

4,738,698,913 would be 1_1A72_CEA1 in hex, but that needs 33 bits.
If you
truncate that to 32 bits, you get 1A72_CEA1. Xor that with 43,814,
which
is AB26 in hex, and you get 1A72_6587, which just happens to be
443,704,711.

But that's assuming that PHP performs XOR on the absolute values of
the operands, and then negates appropriately. i.e.:

(-4,738,698,913 ^ 43,814) == -(4,738,698,913 ^ 43,814)

which isn't the case, at least not always. e.g.:

echo (3 ^ 7) . "\n";
echo (-3 ^ 7) . "\n";

i.e. doing XOR directly on the 2's-complement representations of the
operands.

No, Tim is correct. PHP CAN'T do an XOR on -4,738,698,913 on a 32 bit
system. The value doesn't fit into 32 bits!

I'm aware of that.

However, I now realise that -443,704,711 is the correct answer! Made a
mistake in my paper calculations! Apologies...


--
Oli

[DigDug]

What founded this question is the following script.

http://www.googlecommunity.com/scrip...nk-source.phps

which works on some machines and not others. All my machines are 32bit.

From my tests I noticed the problem being with 2.6 kernel boxes and

not what bit the kernel/processor is.

[Jim Michaels]

How do you know the PHP lexical analyzer or parser is going to lop off a bit
for you? what if it does something else?
your number in hex is 0xFFFF FFFE E58D 315F ^ 0x0000 0000 0000 AB26=0xFFFF
FFFF 8000 AB26
2's complement numbers in hex are represented differently in binary...
this is from pcalc, a program from analogx.com (64-bit programmer's
calculator)

"Tim Roberts" <ti**@probo.com> wrote in message
news:39********************************@4ax.com...

"Chung Leong" <ch***********@hotmail.com> wrote:

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?

First, answer this question: how can you squeeze -4,738,698,913 into a
32-bit variable?

4,738,698,913 would be 1_1A72_CEA1 in hex, but that needs 33 bits. If you
truncate that to 32 bits, you get 1A72_CEA1. Xor that with 43,814, which
is AB26 in hex, and you get 1A72_6587, which just happens to be
443,704,711.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Jim Michaels]

"DigDug" <do*******@hotmail.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...

I get two different results in doing a Xor on a large signed double
between linux servers.
working system is kernel 2.4 . bad results server is kernel 2.6.

PHP version does not matter. I compile PHP from 4.2.2 to latest.

test code:
<?PHP echo -4738698913 ^ 43814; ?>

results:

Good result from 2.4 kernel system is -443704711
Bad result from 2.6 kernel systems(tried 5 different systems) is
-2147439834

2.6 kernel system is at least a 64-bit base. it's not a bug.
-4738698913=0xFFFF FFFE E58D 315F
43814=0x0000 0000 0000 AB26
-2147439834=0xFFFF FFFF 8000 AB26
that last number is what I get for a result from a 64-bit calculator.

When a C or C++ program like PHP is compiled on a 64-bit processor or using
flags for 64-bit int's, you will probably get this. The size of an int will
become 64 bits, not 32. similarly, if you are compiling on a 16-bit
processor and no 32-bit registers are available, you may get 16-bit ints.
The manual doesn't seem to take this into account. possibly 64-bit
processors were not supported until later versions of gcc and/or kernel? or
possibly (more likely) the default settings for the processor are stored in
the kernel.
BUG in PHP or kernel?

[Tim Roberts]

"Jim Michaels" <jm******@yahoo.com> wrote:

How do you know the PHP lexical analyzer or parser is going to lop off a bit
for you? what if it does something else?
PHP does not handle integers larger than "long" on its machine. Thus, on a
32-bit machine, I KNOW it's going to lop off a bit.
your number in hex is 0xFFFF FFFE E58D 315F ^ 0x0000 0000 0000 AB26=0xFFFF
FFFF 8000 AB26
No, that would be my number in a 64-bit variable. My description below
specifically mentions a 32-bit variable, as the OP was using.
2's complement numbers in hex are represented differently in binary...
No, they aren't. The numbers are ALL binary. Whether I print them in
binary or hex or decimal is irrelevant to the way they are processed.
However, the SIZE of the variable is important.
this is from pcalc, a program from analogx.com (64-bit programmer's
calculator)
Right. That's the result you'd get from a 64-bit processor. PHP on a
32-bit processor will produce the result I described.
"Tim Roberts" <ti**@probo.com> wrote in message:

"Chung Leong" <ch***********@hotmail.com> wrote:

How is -4,738,698,913 ^ 43814 = -443,704,711 correct?

First, answer this question: how can you squeeze -4,738,698,913 into a
32-bit variable?

4,738,698,913 would be 1_1A72_CEA1 in hex, but that needs 33 bits. If you
truncate that to 32 bits, you get 1A72_CEA1. Xor that with 43,814, which
is AB26 in hex, and you get 1A72_6587, which just happens to be
443,704,711.

--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Chung Leong]

Oli Filth wrote:

As a side-note:
I don't like the fact that even basic PHP code isn't portable between
platforms, i.e. it doesn't abstract away differences in platform bitwise
implementations of signed values.

I don't really see why the operation would be platform dependent. If I
remember correctly, a long is defined as 32 bit. Int is the one that
varies between architectures. In PHP, a convert from double to integer
is done by the DVAL_TO_LVAL macro, which is defined as:

(l) = (d) > LONG_MAX ? (unsigned long) (d) : (long) (d)

A cast to long should be the same even on a 64 bit OS/CPU.

I wonder if it's a difference in the compiler or C library. Typically a
cast from a float to a long is handled with a call to ftol(). Maybe the
overflow behavior is different.