php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #40543 pack/unpack bug
Submitted: 2007-02-19 13:34 UTC Modified: 2007-05-09 23:29 UTC
Votes:11
Avg. Score:4.7 ± 0.6
Reproduced:10 of 11 (90.9%)
Same Version:9 (90.0%)
Same OS:9 (90.0%)
From: dedmajor at gmail dot com Assigned:
Status: Closed Package: Strings related
PHP Version: 5.2.1 OS: linux x86_64
Private report: No CVE-ID: None
View Developer Edit
 [2007-02-19 13:34 UTC] dedmajor at gmail dot com 
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
)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-02-24 15:12 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.
 [2007-04-12 20:11 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!
 [2007-04-22 18:43 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.
 [2007-04-22 18:44 UTC] petr dot stastny at centrum dot cz 
Sorry, it is converted to SIGNED int
 [2007-04-23 09:18 UTC] tony2001@php.net 
Not reproducible (both on 32bit and 64bit).
 [2007-04-23 17:19 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.
 [2007-04-23 18:03 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
 [2007-04-23 22:07 UTC] petr dot stastny at centrum dot cz 
All right! I just compiled the newest snapshot and it seems to be fixed. Thanks.
 [2007-05-01 01:00 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".
 [2007-05-09 23:29 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.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Oct 28 21:00:01 2025 UTC