Re: phar update
| From: | Marcus Boerger | Date: | Sat, 21 Feb 2009 12:19:11 +0000 |
| Subject: | Re: phar update | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-43142@lists.php.net to get a copy of this message | ||
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