Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43218
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 209.85.200.169 cause and error)
Message-ID: <49AA343E.1070303@chiaraquartet.net>
Date: Sun, 01 Mar 2009 01:07:42 -0600
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Kalle Sommer Nielsen <kalle@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <499F76C6.4010601@chiaraquartet.net>	 <2dedb8a0902210755g1b6268f8p34058d23203e0631@mail.gmail.com>	 <49AA022B.1040701@chiaraquartet.net> <2dedb8a0902282120n42fcf625ge8ccc7d82fb7e23d@mail.gmail.com>
In-Reply-To: <2dedb8a0902282120n42fcf625ge8ccc7d82fb7e23d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] phar update
From: greg@chiaraquartet.net (Greg Beaver)

Kalle Sommer Nielsen wrote:

>>> Phar::getSupportedSignatures()
>>> [C:\php\src\ext\phar\tests\phar_get_supported_signatures_002.phpt]
>> This one is perplexing - I wonder if you have built ext/hash statically
>> or as a .dll?  The phar ext is not detected ext/hash, but the test is
>> not skipping because ext/hash is present in the SKIPIF
> 
> ext/hash was built staticlly (default)
> 
> I looked into the issue and it seems like PHAR_HASH_OK isn't getting
> defined, so I assume its a missing AC_DEFINE call in config.w32, so
> something along the lines of the following should do if ext/hash is
> built staticlly:
> 
> if(PHP_HASH != "no" && !PHP_HASH_SHARED) {
> 	AC_DEFINE("PHAR_HASH_OK", 1);
> }
> 
> using the above code in config.w32 and then buildconf, configure,
> nmake and run-tests on that test makes it pass but the test will still
> fail if ext/hash is built as shared ofcourse.



>>> Phar::setStub() (zip-based) [C:\php\src\ext\phar\tests\zip\phar_stub.phpt]
>> This one is actually troubling, as it looks like a crash is terminating
>> the test at the second setStub()
> 
> I did some more tests and a couple of fresh checkouts and builds and
> this test does not fail anymore for me, if anyone can confirm it would
> be good.

I found the problem, and it's amazing that only windows had this
problem, and only intermittently.  I found different tests would fail,
it's a miracle none failed on the first try for me.  The problem was
that the splitting of a timestamp into date and time fields for zip
format was inadvertantly flipped when I did the most recent commit for
big-endian stuff.  None of the tests confirm that timestamp is
unmodified on load, and so it slipped by.  I'm going to add that to the
test in question shortly, to be certain this doesn't happen again.

Thanks for catching this Kalle, and for the config.w32 fix.

Greg