ID: 42510
User updated by: jr-php2 at quo dot to
Reported By: jr-php2 at quo dot to
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux x86-64
PHP Version: 5.2.4
New Comment:
Okay, looking at the unpack() code, it appears that:
- 'l' and 'L' are both treated as signed, even though 'l' is documented
as signed and 'L' is documented as unsigned.
- 'N' and 'V' are treated as signed, even though both are documented as
unsigned.
So who's right here, the code or the documentation?
Previous Comments:
------------------------------------------------------------------------
[2007-09-01 17:26:12] jr-php2 at quo dot to
Sorry, I mixed up the expected and actual results.
It should say:
Expected result:
----------------
unpack = 3368601800
ip2long = 3368601800
Actual result:
--------------
unpack = -926365496
ip2long = 3368601800
------------------------------------------------------------------------
[2007-09-01 17:22:10] jr-php2 at quo dot to
Description:
------------
On x86-64, unpack('V') sign-extends from 32-bit to 64-bit. In other
words, it can return a negative number.
Since 'V' specifies an *unsigned* 32-bit value, this is incorrect; the
upper 32 bits of the 64-bit result should always be zero.
This behavior makes unpack() inconsistent with other functions like
ip2long() and crc32() which never return negative numbers on 64-bit PHP.
Reproduce code:
---------------
$u = unpack('Vresult', chr(200).chr(200).chr(200).chr(200));
echo "unpack = ", $u['result'], "\n";
echo "ip2long = ", ip2long('200.200.200.200'), "\n";
Expected result:
----------------
unpack = -926365496
ip2long = 3368601800
Actual result:
--------------
unpack = 3368601800
ip2long = 3368601800
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=42510&edit=1
