Hi internals!
I wrote a patch to expose PCRE mark information in PHP, see
https://github.com/php/php-src/pull/609/files. The last passed *MARK will
be added to the $matches array under key "MARK". If you don't use marks
everything stays exactly the same.
Does anyone have a problem with exposing it in this way?
In this context, would there be a problem with increasing the minimum
required PCRE version (for builds against an external library) from 6.6 to
8.10 (the current, bundled version is 8.34)? That would avoid adding
#ifdefs for this code. Is there some particular reason for 6.6 here?
Thanks,
Nikita
Hi internals!
I wrote a patch to expose PCRE mark information in PHP, see
https://github.com/php/php-src/pull/609/files. The last passed *MARK will
be added to the $matches array under key "MARK". If you don't use marks
everything stays exactly the same.Does anyone have a problem with exposing it in this way?
In this context, would there be a problem with increasing the minimum
required PCRE version (for builds against an external library) from 6.6 to
8.10 (the current, bundled version is 8.34)? That would avoid adding
#ifdefs for this code. Is there some particular reason for 6.6 here?Thanks,
Nikita
If I read my RPMs correctly, the PCRE version on Oracle Linux 5 (which
is equivalent to RHEL 5) is 6.6.
Oracle Linux 6 has PCRE 7.8.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Yea, I currently have "7.8-6.el6" on CentOS 6.5.
8.10 is too high a dependency
- Trevor
On Fri, Feb 28, 2014 at 3:59 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:
Hi internals!
I wrote a patch to expose PCRE mark information in PHP, see
https://github.com/php/php-src/pull/609/files. The last passed *MARK will
be added to the $matches array under key "MARK". If you don't use marks
everything stays exactly the same.Does anyone have a problem with exposing it in this way?
In this context, would there be a problem with increasing the minimum
required PCRE version (for builds against an external library) from 6.6 to
8.10 (the current, bundled version is 8.34)? That would avoid adding
#ifdefs for this code. Is there some particular reason for 6.6 here?Thanks,
NikitaIf I read my RPMs correctly, the PCRE version on Oracle Linux 5 (which
is equivalent to RHEL 5) is 6.6.Oracle Linux 6 has PCRE 7.8.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/
underground-php-oracle-manual-098250.html
Yea, I currently have "7.8-6.el6" on CentOS 6.5.
8.10 is too high a dependency
- Trevor
As Christopher pointed out on IRC, the distros shipping PCRE versions in
the 6.x-7.x range are also the ones that still use PHP 5.3 - by the time
they switch to 5.6 as default they'll also use a PCRE version that was
recent at that time.
I don't really have a problem with adding a few ifdefs for this, but 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.
Nikita
It's a bit ridiculous that you can end up using a PHP
version from 2014 together with a decade old PCRE version.
That's an interesting way of looking at it. I don't know enough about
the specifics of this case, but the general idea feels close to a
conversation I had with a colleague the other day, in which he argued
that it doesn't make sense to restrict a new project to an already
out-of-date library just because that's what we're using elsewhere.
Since we were discussing CSS frameworks, any upgrade of old projects
would mean the site was getting a complete overhaul anyway - in the same
way that a PHP 5.6 package would be expected to come with either a
complete release of the distro, or some way of resolving "too new"
dependencies.
I also think that many PHP users don't realise just how tightly PHP's
extensions expose the specifics of a particular version of a 3rd-party
library. They might look at the documentation to check that a particular
function or option was added in PHP 5.4 or 5.5, but they probably
wouldn't even consider checking what version of PCRE (or libxml, etc,
etc) their system had, until they found something in their code
mysteriously "broke" on a particular environment. From that point of
view, the user-friendly approach for a PHP extension is to either
require a newer version of a library, or expose only the "lowest
common denominator" of functionality, so that the documentation can
confidently say "in PHP 5.6, you can do this".
Like I say, I don't know about the specifics of this case, so raising
the requirement may or may not be the right decision here, but it seems
like a useful line of thought.
Regards,
--
Rowan Collins
[IMSoP]
Ah, very good point. CentOS ships with 5.3, so a higher dependency for 3
minor versions greater makes sense.
- Trevor
Yea, I currently have "7.8-6.el6" on CentOS 6.5.
8.10 is too high a dependency
- Trevor
As Christopher pointed out on IRC, the distros shipping PCRE versions in
the 6.x-7.x range are also the ones that still use PHP 5.3 - by the time
they switch to 5.6 as default they'll also use a PCRE version that was
recent at that time.I don't really have a problem with adding a few ifdefs for this, but 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.Nikita
Hi internals!
I wrote a patch to expose PCRE mark information in PHP, see
https://github.com/php/php-src/pull/609/files. The last passed *MARK will
be added to the $matches array under key "MARK". If you don't use marks
everything stays exactly the same.Does anyone have a problem with exposing it in this way?
In this context, would there be a problem with increasing the minimum
required PCRE version (for builds against an external library) from 6.6 to
8.10 (the current, bundled version is 8.34)? That would avoid adding
#ifdefs for this code. Is there some particular reason for 6.6 here?
I merged this with ifdefs for now (ping me if you have build issues, I
didn't actually test this).
It would still be nice to increase the minimum version number for 5.6,
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.
Nikita
2014.03.17. 22:52, "Nikita Popov" nikita.ppv@gmail.com ezt írta:
On Fri, Feb 28, 2014 at 9:37 PM, Nikita Popov nikita.ppv@gmail.com
wrote:Hi internals!
I wrote a patch to expose PCRE mark information in PHP, see
https://github.com/php/php-src/pull/609/files. The last passed *MARK
will
be added to the $matches array under key "MARK". If you don't use marks
everything stays exactly the same.Does anyone have a problem with exposing it in this way?
In this context, would there be a problem with increasing the minimum
required PCRE version (for builds against an external library) from 6.6
to
8.10 (the current, bundled version is 8.34)? That would avoid adding
#ifdefs for this code. Is there some particular reason for 6.6 here?I merged this with ifdefs for now (ping me if you have build issues, I
didn't actually test this).It would still be nice to increase the minimum version number for 5.6,
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.Nikita
+1 for bumping the minimum pcre version requirement.
Could we check what major linux distros ship currently just to be safe?
I wrote a patch to expose PCRE mark information in PHP, see
https://github.com/php/php-src/pull/609/files. The last passed *MARK will
be added to the $matches array under key "MARK". If you don't use marks
everything stays exactly the same.
Hi,
Have you considered using a key that cannot be mistaken for (or
interfere with) a named capture called "MARK"? How about "*MARK"?