Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87715
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <55CA372B.8040006@gmx.de>
References: <55CA26DF.3030109@gmx.de> <CADajX4BQf3kL3_8M_zHRrMLUOcjdJ7nL1ERaJiDyL6=61S0k6A@mail.gmail.com>
 <55CA372B.8040006@gmx.de>
Date: Wed, 12 Aug 2015 04:59:45 +0900
Message-ID: <CAGa2bXbyH7dOzAL-wY=nn=yerawXPL7_F4cyTy6=P0zgkKAaOA@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: Adam Harvey <aharvey@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11490c148b644e051d0e8d60
Subject: Re: [PHP-DEV] libpcre version requirements
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11490c148b644e051d0e8d60
Content-Type: text/plain; charset=UTF-8

Hi all,

On Wed, Aug 12, 2015 at 2:55 AM, Christoph Becker <cmbecker69@gmx.de> wrote:

> >> 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).
> >
> > I guess the question's really whether we should still support an
> > _external_ libpcre that old, since we bundle much newer versions. I
> > think the argument against changing it has always been that it works
> > and we didn't need anything newer, but if we have a reason now then
> > that doesn't really hold.
> >
> > One problem is that I don't think we can really change the minimum
> > requirement on a stable branch, so for 5.5 and 5.6 we're going to have
> > to implement something that works with older versions regardless, but
> > I'd be for bumping the minimum version requirement for 7.0 if it makes
> > the code cleaner (on that branch, at least) moving forward.
>
> I don't know if we can implement a fully working fallback for PCRE < 8
> in a viable way.  Actually, PCRE_NOTEMPTY_ATSTART had been added to
> libpcre to solve the issue with \K for /g[1].  Note the wording of the
> commit message:
>
> | Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly
> | implement the /g option in pcretest when the pattern contains \K,
> | [...]
>
> My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to
> PCRE_NOTEMPTY, if the former is not available.  Of course the bug would
> persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway.


Isn't it normal that PHP would not support features that underlying libs do
not
support? We have number of such functions. Isn't it the reason why
phpinfo()
shows underlying library versions?

Distributions prefer to use system's libraries. I suppose question is if
PHP
supports older systems such as RHEL/CentOS 5 or not. They are used widely.
I prefer to support them if it is possible/feasible. Features that are not
supported
by libs could be documentation issues.  IMO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11490c148b644e051d0e8d60--