Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87723
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
Message-ID: <55CA646F.8020506@gmx.de>
Date: Tue, 11 Aug 2015 23:09:03 +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: Anatol Belski <anatol.php@belski.net>, 
 'PHP internals' <internals@lists.php.net>
References: <55CA26DF.3030109@gmx.de> <03dd01d0d476$c75b6730$56123590$@belski.net>
In-Reply-To: <03dd01d0d476$c75b6730$56123590$@belski.net>
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 22:46, Anatol Belski wrote:

>> -----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.

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.

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.

Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0
for PHP 7.0 or at least for PHP 7.1.

-- 
Christoph M. Becker