Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87837
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <066a01d0d61f$4937d370$dba77a50$@belski.net>
References: <55CA26DF.3030109@gmx.de>
	<03dd01d0d476$c75b6730$56123590$@belski.net>
	<55CA646F.8020506@gmx.de>
	<040101d0d4ca$656f4e20$304dea60$@belski.net>
	<55CC80FC.5070306@gmx.de>
	<CADajX4CcuDJLQtEjcS+-O_Dr9yYerRe4M=hyn1oP_Bggifmp8A@mail.gmail.com>
	<066a01d0d61f$4937d370$dba77a50$@belski.net>
Date: Fri, 21 Aug 2015 15:14:16 +0200
Message-ID: <CAF+90c-KkntMjB9H+zm87XqY24-zqWHmP_mLF00qm-pMqaxkWQ@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Adam Harvey <aharvey@php.net>, Christoph Becker <cmbecker69@gmx.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3d3e276af2b051dd20bac
Subject: Re: [PHP-DEV] libpcre version requirements
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c3d3e276af2b051dd20bac
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski <anatol.php@belski.net>
wrote:

>
>
> > -----Original Message-----
> > From: adam@adamharvey.name [mailto:adam@adamharvey.name] On Behalf
> > Of Adam Harvey
> > Sent: Thursday, August 13, 2015 8:44 PM
> > To: Christoph Becker <cmbecker69@gmx.de>
> > Cc: Anatol Belski <anatol.php@belski.net>; PHP internals
> > <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] libpcre version requirements
> >
> > On 13 August 2015 at 04:35, Christoph Becker <cmbecker69@gmx.de> wrote:
> > > On 12.08.2015 at 08:44, Anatol Belski wrote:
> > >>
> > >> [...] 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 h=
ow
> > 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 bein=
g
> 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.
> > >
> > > Well, then it might be best to leave the requirements as they are for
> > > now. :)
> >
> > I'm still OK requiring 8.00 in PHP 7.0, personally =E2=80=94 even that =
is almost
> six years
> > old, and users on older distros and OSes can use the bundled libpcre.
> It's not like
> > this is going to break the common case where the user doesn't set any
> specific
> > PCRE flags in configure, and I don't think it's unreasonable to expect
> third party
> > packagers to use a bundled library if they're building on that old a
> system.
> > They're effectively shouldering the burden of providing security update=
s
> for PHP
> > regardless of what the distro does.
>
> What about the other 65% of the market share where we have no idea what
> happens? Well, some of them are Windows where bundled PCRE is used, but t=
he
> rest is like UNIXes, maybe they're 50/50 or alike.
>
> Besides that - an average user won't even have gcc installed to use the
> bundled PCRE or not, and what packagers would do - yep, that's a question=
.
> However distributions usually enforce shared libs usage for the exact
> reason to centralize delivery of the (security) updates.
>
> I would suggest to make this move (raising the PCRE version to 7 or 8) in
> master after 7.0 is branched. Then there were enough time to see how 7.0 =
is
> being handled, to get feedback on that change and to react accordingly, i=
f
> needed.
>
> Regards
>
> Anatol
>

There already was some discussion about bumping the libpcre version for
5.6. I'll quote what I said back then:

> [...] I think the low version requirement is bad for other reasons:
There's a big gulf in terms of both features and bug fixes between PCRE 6.6
and what PHP currently bundles. It's a bit ridiculous that you can end up
using a PHP version from 2014 together with a decade old PCRE version.

and

> It would still be nice to increase the minimum version number [...],
because allowing prehistoric PCRE versions in a new release makes zero
sense. I recommend at least 8.10 because it both supports marks and - more
relevantly to most users - supports UCP mode, which PHP uses by default (if
available). UCP mode can significantly change the behavior of PCRE with the
/u modifier, as such guaranteeing a minimum version of 8.10 will also
guarantee a somewhat consistent /u behavior.

Basically, if we allow a too broad range of PCRE versions, we also allow a
broad range of behavior people have to deal with. If people use the /u
modifier, they will get significantly (and at the same time subtly)
different behavior if PHP was linked against libpcre newer or older than
8.10.

Distros that will ship with PHP 7 will also ship with new PCRE versions.
External package repositories with PHP 7 will also have newer PCRE
versions. People compiling themselves use the bundled version.

Let's bump this. If you install PHP 7 in 2016 you should *not* have to deal
with a PCRE version released in 2006.

Nikita

--001a11c3d3e276af2b051dd20bac--