Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64922
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50F38B27.3080801@oracle.com>
References: <B4E39E8F-B971-4909-9F79-612788FD2E6B@wiedler.ch>
	<50DD61A0.30502@fedoraproject.org>
	<50F38B27.3080801@oracle.com>
Date: Mon, 14 Jan 2013 00:57:01 -0500
Message-ID: <CAL+t6cH2UZxYxHTXMgV4LnrbsWK0uJbgXvBbz3YexHVFzxsOpg@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: Remi Collet <remi@fedoraproject.org>, PHP Internals <internals@lists.php.net>, 
	=?ISO-8859-1?Q?Gustavo_Andr=E9_dos_Santos_Lopes?= <cataphract@php.net>
Content-Type: multipart/alternative; boundary=089e013c6c12620e1804d339507e
Subject: Re: [PHP-DEV] PHP-5.5 unpack change broke pecl/pear
From: theanomaly.is@gmail.com (Sherif Ramadan)

--089e013c6c12620e1804d339507e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 13, 2013 at 11:35 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:

>
>
> On 12/28/2012 01:08 AM, Remi Collet wrote:
>
>> Le 24/12/2012 04:16, Igor Wiedler a =E9crit :
>>
>>> Hi Internals,
>>>
>>> When test driving PHP-5.5 I ran into issues with a change of unpack
>>> behaviour. Archive_Tar which is used by pecl and pear (`pecl install`) =
uses
>>> unpack with the "a" format character. On 5.4 it strips trailing NUL byt=
es,
>>> on 5.5 it does not. There is a new "Z" format character that can be use=
d to
>>> get the old behaviour. The point is, this change broke pecl, and will
>>> likely break many other things in existence.
>>>
>>
>>
>>> Anthony has asked me to post to internals, so that you can re-visit the
>>> issue and perhaps consider not breaking BC.
>>>
>>> If you decide that you want to keep the BC break, I will gladly submit =
a
>>> patch for Archive_Tar.
>>>
>>
>> See http://pear.php.net/bugs/bug.**php?id=3D19746<http://pear.php.net/bu=
gs/bug.php?id=3D19746>
>>
>> Remi.
>>
>>
>>> Thanks,
>>>
>>> Igor
>>>
>>>
>>
>>
> Sherif,
>
> Are you "owning" this issue?
> I assigned bug https://bugs.php.net/bug.php?**id=3D63073<https://bugs.php=
.net/bug.php?id=3D63073>to you in case you are.
>


It was discussed on IRC that this change was applied in order to bring
PHP's implementation of pack() to be more inline with Perl's implementation
(see https://bugs.php.net/61038 for details) and thus why the change was
introduced in PHP 5.5 instead of 5.4, which was already final at the time.
The BC was taken into consideration, but the manual never specified that
this was the defined behavior. So we had made the decision at the time that
this BC would be worth taking in 5.5 for bringing the implementations
inline.

The BC concerns seem to be fiarly limited in in immediate scope to
Archive_Tar, which seems to be a trivial patch (see
http://pear.php.net/bugs/bug.php?id=3D19746&edit=3D12&patch=3Darchive_tar_p=
hp55.patch&revision=3D1355241213also)
and Igor
Wiedler seems willing to apply it. Obviously there can more BC out there
with people that rely on this behavior in their existing code, but I can
not gauge this if I just base it on the number of open bugs in the bug
tracker that have to do with pack and PHP 5.5.

So in light of these events the plan is to ask that Archive_Tar be patched
to resolve the make install issue and remain consistent with the Perl
implementation, which also seems consistent with Ruby's implementation of
pack. The spec itself seems a bit ambiguous as noted earlier in this
thread, but I think PHP will benefit more from being consistent with the
other implementations.

Please let me know if there are other BC concerns that have not yet come up=
.



> Chris
>
> --
> christopher.jones@oracle.com  http://twitter.com/ghrd
> Newly updated, free PHP & Oracle book:
> http://www.oracle.com/**technetwork/topics/php/**
> underground-php-oracle-manual-**098250.html<http://www.oracle.com/technet=
work/topics/php/underground-php-oracle-manual-098250.html>
>

--089e013c6c12620e1804d339507e--