Don't ask to ask, just ask | |
PerlMonks |
Re^2: Integer overflowby gone2015 (Deacon) |
on Apr 24, 2009 at 11:16 UTC ( [id://759804]=note: print w/replies, xml ) | Need Help?? |
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: 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:
In Section
Seekers of Perl Wisdom
|
|