Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Christoph Becker'" <cmbecker69@gmx.de>,
	"'PHP internals'" <internals@lists.php.net>
References: <55CA26DF.3030109@gmx.de> <03dd01d0d476$c75b6730$56123590$@belski.net> <55CA646F.8020506@gmx.de>
In-Reply-To: <55CA646F.8020506@gmx.de>
Date: Wed, 12 Aug 2015 08:44:50 +0200
Message-ID: <040101d0d4ca$656f4e20$304dea60$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH7++SmR5Qqa5F1jGgVRfCNseMOmgMakR6SAY8BXI+di7eF4A==
Content-Language: en-us
Subject: RE: [PHP-DEV] libpcre version requirements
From: anatol.php@belski.net ("Anatol Belski")


> -----Original Message-----
> From: Christoph Becker [mailto:cmbecker69@gmx.de]
> Sent: Tuesday, August 11, 2015 11:09 PM
> To: Anatol Belski <anatol.php@belski.net>; 'PHP internals'
> <internals@lists.php.net>
> Subject: Re: [PHP-DEV] libpcre version requirements
>=20
> On 11.08.2015 at 22:46, Anatol Belski wrote:
>=20
> >> -----Original Message-----
> >> From: Christoph Becker [mailto:cmbecker69@gmx.de]
> >> Sent: Tuesday, August 11, 2015 6:46 PM
> >> To: PHP internals <internals@lists.php.net>
> >> Subject: [PHP-DEV] libpcre version requirements
> >>
> >> What is the minimum libpcre version that is supported as external
> >> libpcre for ext/pcre?  According to config0.m4 it is PCRE 6.6
> >> (2006-02-06), but is this still valid and do we really have to =
support such old
> versions?
> >>
> >> I'm asking because of bug #70232 which can easily be fixed, but =
that
> >> requires PCRE 8.00 (2009-10-19).  If we have to support older PCRE
> >> versions, we'd probably need a fallback to the current behavior
> >> (which would obviously keep the bug).
> >
> > IMHO the dependent version shouldn't be raised. But not sure what is =
meant
> by "implementing for lower versions". Probably if it's missing in =
PCRE, so is it.
> We should avoid reimplementing it, but just doing what is done in the =
other exts,
> fe curl. Users can choose to upgrade the dependency or to miss the =
feature. So
> a compile time PCRE version check were enough.
>=20
> The difference to cURL, AIUI, is that this is not about an option that =
can be
> supplied by the user (and checked for existance in user-land code, by =
e.g.
> defined(CURLOPT_*)), but rather something that is for internal use =
only, and
> therefore much less obvious for user-land developers.
>=20
> IOW: fixing bug #70232 is trivial, but the bug would still persist for =
libpcre 7.2 -
> 7.9.  If that's not regarded as a general issue, I'm fine with it.
>=20
> Still, I would suggest to raise the libpcre requirements to PCRE >=3D =
8.0 for PHP 7.0
> or at least for PHP 7.1.
>=20
Yeah, it's different from curl in some ways. However look - =
http://w3techs.com/technologies/details/os-linux/all/all . From those, =
CentOS 5/6 releases are not even a year old and contain 6.6, 7.x but =
take 20% of all the Linux market share. Note that according to that =
Linux takes only 35.9% of it. Now, say disregarding CentOS 5 and other =
rare/too old platforms, the other 65% of the usages are not taken into =
account. So how much loss on PHP7 adoption would happen, is a question. =
Maybe there are other stats, just operating on what is available.

On the other hand  - as with the bug #70232, is it really worth =
disabling the whole PCRE just to be sure one bug is fixed? I would see =
it as not being such.  It is clear, that no distro will suddenly be =
upgrading from say PHP 5.3 to PHP7 in an older branch, but keeping as =
much compat as possible will allow third party repositories to still =
provide PHP7 there. This is at least my reason to say the version =
shouldn't be raised - as it shouldn't go beyond 7.x at least because of =
CentOS 6, and then it is probably useless to do it ATM. As long as it =
doesn't block the work towards future, at least.

Regards

Anatol