Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43142
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Sat, 21 Feb 2009 13:19:11 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1121157883.20090221131911@marcus-boerger.de>
To: Greg Beaver <greg@chiaraquartet.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <499F76C6.4010601@chiaraquartet.net>
References: <499F76C6.4010601@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] phar update
From: helly@php.net (Marcus Boerger)

Hello Greg,

  in one word: Awesome!

Saturday, February 21, 2009, 4:36:38 AM, you wrote:

> 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




Best regards,
 Marcus