Perl Math Question

[Chris Pruett]

An odd (to me) behavior I was hoping someone could explain.

Take the simple command:

perl -e 'print 0xCEC5 + 0xFFFFE253 & 0xFFFF'

I tried this on a number of computers. Most give 0xFFFF, which just
seems wrong. This includes Perl 5.6 and 5.8 on Linux and Darwin (OSX).
Also one Solaris box with 5.0. One computer (Perl 5.6, HPUX) gave what
I thought to be the correct answer (0xB118). Is this some sort of type
conversion issue that trips up the 32-bit PowerPCs and x86s but the
64-bit HPUX avoids?

Interestingly,

perl -e 'print 0xCEC5 + 0xFFFFE253 & 0xBEEF'

0xBEEF

Neat trick. Totally wrong answer, though.

perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

gives 0x10000B118, which I don't understand.

perl -e 'print 0xCEC5 + (0xFFFFE253 & 0xFFFF)'

gives 0x1B118, which makes sense.

Obviously, I'm not grokking the perl bitwise-and (&) operator. The FAQ
warned about accidently anding strings, but stuff like

print oct("0xCEC5") + oct("0xFFFFE253") & oct("0xFFFF")

also gets the wrong answer, so I don't think that's my problem.

Any enlightenment appreciated.

CP

--
'When religion and politics ride in the same cart, the whirlwind follows.'

[Lesley]

Chris Pruett <sp**@pruett.org> wrote in message news:<150920032356168229%sp**@pruett.org>...

<snip> perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

gives 0x10000B118, which I don't understand.

<snip>

This is hexadecimal arithmetic (not maths ;-> ) and the answer is
correct.

Simply add 0xCEC5 to 0xFFFFE253 and the result is 0x10000B118.

Anding 0xFFFF with 0x10000B118, leaves the least significant four
digits alone
i.e. in binary, bitwise anding 1010 with 1111 and you get 1010.

Perl does not appear to left fill 0xFFFF with leading zeroes so you do
not lose the five most significant digits of the addition result. I
would hesitate to say that perl is left filling with 1's on an and
operation; rather that it performs the bitwise operation on as many
bits as are appropriate; in this example the least significant four.

HTH

Lesley

[Bill N1VUX]

> >perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

gives 0x10000B118, which I don't understand.

This is hexadecimal arithmetic (not maths ;-> ) and the answer is
correct.

However, perl -we will give a warning, which may help the understanding.
The &0xFFFF is applied to the return value of the print.

[Chris Pruett]

In article <3F***************@world.std.com>, Bill N1VUX
<wd*@world.std.com> wrote:

perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'
gives 0x10000B118, which I don't understand.

This is hexadecimal arithmetic (not maths ;-> ) and the answer is
correct.

However, perl -we will give a warning, which may help the understanding.
The &0xFFFF is applied to the return value of the print.

Thanks for the reply.

Interesting point about the return value of the print. That seems to
explain how I get 0x10000B118 from

perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

I'm still on my quest to get the right answer though (0xB118).

$x = (0xCEC5 + 0xFFFFE253);
print "$x\n";
$x &= 0xFFFF;
print "$x\n"'

4295012632 [0x10000B118]
65535 [0xFFFF]

That's still not the answer I expect.

In the $x &= 0xFFFF, does Perl try to convert the 0x10000B118 to a
native integer type (32-bit), detect the overflow, and saturate the
result (0xFFFFFFFF) before applying the bitwise-and? That would seem
to explain some of the results I'm getting and it might explain why
the 64-bit HPUX version gets the correct number.
CP

--
'When religion and politics ride in the same cart, the whirlwind follows.'