FAQ
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

Search Discussions

  • Christopher Jones at Feb 28, 2014 at 8:59 pm

    On 02/28/2014 12:37 PM, Nikita Popov 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,
    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
  • Trevor Suarez at Mar 1, 2014 at 12:10 am
    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 wrote:


    On 02/28/2014 12:37 PM, Nikita Popov 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,
    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Nikita Popov at Mar 1, 2014 at 12:30 am

    On Sat, Mar 1, 2014 at 1:10 AM, Trevor Suarez wrote:

    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
  • Rowan Collins at Mar 1, 2014 at 2:20 pm

    On 01/03/2014 00:30, Nikita Popov wrote:
    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]
  • Trevor Suarez at Mar 18, 2014 at 2:54 pm
    Ah, very good point. CentOS ships with 5.3, so a higher dependency for 3
    minor versions greater makes sense.

    - Trevor

    On Fri, Feb 28, 2014 at 7:30 PM, Nikita Popov wrote:
    On Sat, Mar 1, 2014 at 1:10 AM, Trevor Suarez wrote:

    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
  • Nikita Popov at Mar 17, 2014 at 9:52 pm

    On Fri, Feb 28, 2014 at 9:37 PM, Nikita Popov 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
  • Ferenc Kovacs at Mar 18, 2014 at 6:13 am
    2014.03.17. 22:52, "Nikita Popov" <nikita.ppv@gmail.com> ezt írta:
    On Fri, Feb 28, 2014 at 9:37 PM, Nikita Popov 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?
  • Josh Davis at Mar 18, 2014 at 6:23 am

    On 28 February 2014 21:37, Nikita Popov wrote:
    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"?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 28, '14 at 8:37p
activeMar 18, '14 at 2:54p
posts9
users6
websitephp.net

People

Translate

site design / logo © 2021 Grokbase