| Bug #40543 | pack/unpack bug | ||||
|---|---|---|---|---|---|
| Submitted: | 19 Feb 2007 1:34pm UTC | Modified: | 9 May 2007 11:29pm UTC | ||
| From: | dedmajor at gmail dot com | Assigned to: | |||
| Status: | Closed | Category: | Strings related | ||
| Version: | 5.2.1 | OS: | linux x86_64 | ||
| Votes: | 11 | Avg. Score: | 4.7 ± 0.6 | Reproduced: | 10 of 11 (90.9%) |
| Same Version: | 9 (90.0%) | Same OS: | 9 (90.0%) | ||
[24 Feb 2007 3:12pm UTC] iliaa@php.net
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You should be using either L or V, not N.
[12 Apr 2007 8:11pm UTC] wez@php.net
This isn't bogus, this is a real bug that causes pain.
N is there for people writing code that talks to network services that
need to convert numbers from network byte order to the native format.
Also note that we get a bonus crash bug on 64-bit platforms too:
$fail = '\x00\x00\x00\x8c';
$result = unpack('Nsize', $fail);
$size = $result['size'] & 0xffffffff; // BANG!
[22 Apr 2007 6:43pm UTC] petr dot stastny at centrum dot cz
The problem is that first 32 bits are set to 1 (not 0) in the output of unpack() function, thus it is interpreted as very large number and then converted to unsigned int for PHP representation.
[22 Apr 2007 6:44pm UTC] petr dot stastny at centrum dot cz
Sorry, it is converted to SIGNED int
[23 Apr 2007 9:18am UTC] tony2001@php.net
Not reproducible (both on 32bit and 64bit).
[23 Apr 2007 5:19pm UTC] petr dot stastny at centrum dot cz
Okay, I will say exactly where I have this problem:
PHP 5.2.1
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
# uname -a
Linux silver 2.6.18-8.1.1.el5 #1 SMP Mon Apr 9 09:43:24 EDT 2007 x86_64
x86_64 x86_64 GNU/Linux
php -r 'print_r(unpack("N", pack("N", 41445)));
returns the same as metioned int the original message about this bug:
-2147442203
If you use sprintf('%b',....), you can see:
1111111111111111111111111111111110000000000000001010000111100101
First 32 bits are set to 1.
There is no problem on Intel Xeon 64-bit processor as I could test.
[23 Apr 2007 6:03pm UTC] tony2001@php.net
Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip
[23 Apr 2007 10:07pm UTC] petr dot stastny at centrum dot cz
All right! I just compiled the newest snapshot and it seems to be fixed. Thanks.
[1 May 2007 1:00am UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[9 May 2007 11:29pm UTC] iliaa@php.net
This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better.
Description: ------------ #38770 not fixed(?) in 5.2.1-dev on x86_64 AMD Opteron(tm) Processor 265 unpack don't work, on i686 Intel(R) Celeron(R) CPU 2.50GHz works fine for example. Reproduce code: --------------- php -r 'print_r(unpack("N", pack("N", 41445))); Expected result: ---------------- Array ( [1] => 41445 ) Actual result: -------------- Array ( [1] => -2147442203 )