my $result = unpack "l", pack "l", 1729080737 + 72 * 14 * 425567;
In this case the arithmetic gives an unsigned 32-bit integer, and all is well...
...though I note it works because pack('l', ...) silently accepts a value outside -0x8000_0000..+0x7FFF_FFFF and packs away the LS 4 bytes of it's machine representation. I haven't found where that is documented... In this case that can be avoided by using pack('L', ...).
I wondered about more general/extreme cases, for example:
which works fine on 64 bit integer systems, but on a 32 bit one the result is:my $result = 1729080737 + 72 * 14 * 425567 + 0xFFFF_FFFF ; print $result, "\n" ; print $result & 0xFFFF_FFFF, "\n" ; print unpack('l', pack('l', $result)), "\n" ;
6453019568 4294967295 -1because Perl happily does the arithmetic in ~54 bits of "integer in floating point form" (assuming IEEE-754 double), but when an integer in integer form is required, gives 0xFFFF_FFFF for anything > 0xFFFF_FFFF (and -0x8000_0000 for anything < -0x8000_0000) even if the operation would happily mask down to 32 bits :-( I don't know of a simple way to persuade Perl to give the LS 32 bits of an integer which may or may not be held as a float.
use integer wrapped around the arithmetic gives the expected result on both 32 and 64 bit systems.
Avoiding pack (in order to avoid giving an out of range argument) is a bit messy, but I believe this works for both 64 and 32 bit systems:
{ my $q = $result & 0xFFFF_FFFF ; $result = $q <= 0x7FFF_FFFF ? $q : -1 - ($q ^ 0xFFFF_FFFF) ; } ;
In reply to Re^2: Integer overflow
by gone2015
in thread Integer overflow
by terranullis
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |