Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
Message-ID: <55CA372B.8040006@gmx.de>
Date: Tue, 11 Aug 2015 19:55:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Adam Harvey <aharvey@php.net>
CC: PHP internals <internals@lists.php.net>
References: <55CA26DF.3030109@gmx.de> <CADajX4BQf3kL3_8M_zHRrMLUOcjdJ7nL1ERaJiDyL6=61S0k6A@mail.gmail.com>
In-Reply-To: <CADajX4BQf3kL3_8M_zHRrMLUOcjdJ7nL1ERaJiDyL6=61S0k6A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] libpcre version requirements
From: cmbecker69@gmx.de (Christoph Becker)

On 11.08.2015 at 19:01, Adam Harvey wrote:

> On 11 August 2015 at 09:46, Christoph Becker <cmbecker69@gmx.de> wrote:
>> 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?
> 
> CentOS/RHEL 5 provides libpcre 6.6, which is probably where that
> specific minimum version comes from. Someone out there is probably
> still building packages that rely on this.

FWIW, this PCRE 6.6 requirement has been introduced with commit 1ad21d9b
in May 2006, thus before CentOS/RHEL 5.0 had been released.  It seems to
me that nobody simply touched this requirement since then.  Actually
some features already require more recent libpcre, for instance, the \K
modifier requires PCRE 7.2.

>> 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.

[1]
<https://lists.exim.org/lurker/message/20090911.102109.6e80cce4.pt-BR.html>

-- 
Christoph M. Becker