Description:
------------
Testing unpack 'I' format on a 64bit big-endian architecture.
The result depends on the sign bit in the *next* integer in the packed buffer 
or a out of buffer byte if it is not that long.

A patch which resolves this is below.

I think the code ends up producing identical results for the I and i
format which may be the most desirable thing but the code looks like it was
intended to behave differently. Maybe it can be simplified.

Similar to bug #40894 but a different format (I).

patch:
*** pack.c      Thu Mar 11 15:05:11 2010
--- pack.c.orig Thu Mar 11 15:03:20 2010
***************
*** 752,758 ****

                                                if (type == 'i') {
                                                        issigned = input[inputpos + (machine_little_endian ? (sizeof(int) - 1) : 0)] & 0x80;
!                                               } else if (sizeof(long) > 4 && input[inputpos + (machine_little_endian ? (sizeof(int) - 1) : 0)] & 0x80 == 0x80) {
                                                        v = ~INT_MAX;
                                                }

--- 752,758 ----

                                                if (type == 'i') {
                                                        issigned = input[inputpos + (machine_little_endian ? (sizeof(int) - 1) : 0)] & 0x80;
!                                               } else if (sizeof(long) > 4 && (input[inputpos + machine_endian_long_map[3]] & 0x80) == 0x80) {
                                                        v = ~INT_MAX;
                                                }


Test script:
---------------
<?php

echo PHP_INT_MAX."\n";
print_r(unpack('I', pack('I', -10000) . pack('I', 10000)));
print_r(unpack('I', pack('I', -10000) . pack('I', -10000)));

?>

Expected result:
----------------
9223372036854775807
Array
(
    [1] => -10000
)
Array
(
    [1] => -10000
)

Actual result:
--------------
9223372036854775807
Array
(
    [1] => 4294957296
)
Array
(
    [1] => -10000
)