Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43138
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 209.85.200.172 cause and error)
Message-ID: <499F76C6.4010601@chiaraquartet.net>
Date: Fri, 20 Feb 2009 21:36:38 -0600
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: phar update
From: greg@chiaraquartet.net (Greg Beaver)

Hi,

As PHP has the good fortune of being blessed with Scott MacVicar who
connected me with the ppc64 test machine provided by IBM and the sparc
machine provided by Sun through David Soria-Parra (thank you thank you
thank you), phar has now been verified as working in the following
configurations that were previously untested:

64-bit, big-endian, gcc linux
64-bit, big-endian, suncc SunOS

This means phar has been verified as working by me on the following
configurations:

32-bit, little-endian, gcc linux
64-bit, little-endian, gcc Darwin OS X
32-bit, little-endian, MS Windows XP
64-bit, little-endian, gcc linux
64-bit, big-endian, gcc linux
64-bit, big-endian, suncc, SunOS

When I say working, I mean 100% of non-skipped tests passing, no compile
warnings.  The tests exert 80% code coverage, mostly leaving untestable
stuff like errors that are only likely to occur when the disk crashes.

In addition, I discovered potential problems with the zip
implementation, in that the code originally used a packed struct, taking
advantage of #pragma pack on windows and sgi, __attribute for gcc. 
However, it did not work with sun's cc, and on further reading, I
discovered that using a packed struct without specific compiler flags
could lead to bus errors on sparc machines, and to page faults on
windows 64-bit.  The specific compiler flags to fix this would result in
a slower PHP, which was unacceptable.

Thus, I undertook a refactoring of the way zip's structs are accessed,
taking advantage of the fact that structs of char arrays are never
padded, and use some simple math to convert char[4] to php_uint32 and
char[2] to php_uint16.  The code is much simpler, works without #ifdef
on both big-endian and little-endian systems, and has no risk of failing
with any future compilers or OSes as it doesn't rely on
compiler-specific processing commands.

To be clear: this issue did not affect tar-based phars, or phar-based
phars, and only affected zip-based phars on SunOS with sun CC, or on any
Sparc machine or Windows 64-bit if and only if the specific zip file
would cause a read across a word boundary (whew).  And also to be clear:
this problem is ancient history now.

I do need some help verifying phar as working with the following
configurations:

any endian any unix with intel CC
any Windows Vista
64-bit Windows XP
any other supported OS/compiler/processor combo I didn't list.

Verification is as simple as compiling PHP 5.3 from CVS or snap and
running the tests.

Also thanks to those raising concerns about phar, it has served to make
it stronger.

Thanks,
Greg