On 11.08.2015 at 19:01, Adam Harvey wrote: > On 11 August 2015 at 09:46, Christoph Becker <cmbecke...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
