problem with PHP_Archive-based phars tracked to odd unpack() bug

I just pushed out a release of PHP_Archive 0.9.1. This release fixes a bug that affects 64-bit users of PHP 5.2 and newer. Basically, the unpack() function does not behave in a predictable way when unpacking large integers. This is a known bug, and is documented at the manual page, although I was unaware of the issue until today.

It turns out that this code behaves differently on most platforms:

On some systems, instead of int(3068571189), the output is int(-1226396107) even though the V argument specifically requests unsigned integers

It wouldn't matter, except that number happens to be the crc32 checksum of PEAR.php, and so a different number returned meant that the .phar that installs PEAR simply wouldn't work.

The workaround that allows .phars to work in all PHP versions is to convert the unpacked integer into an unsigned integer string using the equivalent of this code:

I hope this is useful to others who are working with unpack()/pack() - be wary, some things don't act like you think they might unless you have great knowledge of the deployment environments, and know what to expect.

Thanks to Ilia and Sara for providing the tips needed to solve this one