/[pcre]/code/trunk/doc/html/pcrepattern.html

Diff of /code/trunk/doc/html/pcrepattern.html

Parent Directory | Revision Log | View Patch Patch

-revision 452 by ph10,
Sat Apr 11 14:34:02 2009 UTC
+revision 453 by ph10,
Fri Sep 18 19:12:35 2009 UTC
 Line 644 
 U+DFFF. Such characters are not valid in
  cannot be tested by PCRE, unless UTF-8 validity checking has been turned off
  (see the discussion of PCRE_NO_UTF8_CHECK in the
  <a href="pcreapi.html"><b>pcreapi</b></a>
- page).
+ page). Perl does not support the Cs property.
  </P>
  <P>
- The long synonyms for these properties that Perl supports (such as \p{Letter})
+ The long synonyms for property names that Perl supports (such as \p{Letter})
  are not supported by PCRE, nor is it permitted to prefix any of these
  properties with "Is".
  </P>
 Line 1922 
 recursively to the pattern in which it a
  Obviously, PCRE cannot support the interpolation of Perl code. Instead, it
  supports special syntax for recursion of the entire pattern, and also for
  individual subpattern recursion. After its introduction in PCRE and Python,
- this kind of recursion was introduced into Perl at release 5.10.
+ this kind of recursion was subsequently introduced into Perl at release 5.10.
  </P>
  <P>
  A special item that consists of (? followed by a number greater than zero and a
 Line 1932 
 call, which is described in the next sec
  a recursive call of the entire regular expression.
  </P>
  <P>
- In PCRE (like Python, but unlike Perl), a recursive subpattern call is always
- treated as an atomic group. That is, once it has matched some of the subject
- string, it is never re-entered, even if it contains untried alternatives and
- there is a subsequent matching failure.
- </P>
- <P>
  This PCRE pattern solves the nested parentheses problem (assume the
  PCRE_EXTENDED option is set so that white space is ignored):
  <pre>
-Line 2028 
 recursing), whereas any characters are p
+Line 2022 
 recursing), whereas any characters are p
  In this pattern, (?(R) is the start of a conditional subpattern, with two
  different alternatives for the recursive and non-recursive cases. The (?R) item
  is the actual recursive call.
+ <a name="recursiondifference"></a></P>
+ <br><b>
+ Recursion difference from Perl
+ </b><br>
+ <P>
+ In PCRE (like Python, but unlike Perl), a recursive subpattern call is always
+ treated as an atomic group. That is, once it has matched some of the subject
+ string, it is never re-entered, even if it contains untried alternatives and
+ there is a subsequent matching failure. This can be illustrated by the
+ following pattern, which purports to match a palindromic string that contains
+ an odd number of characters (for example, "a", "aba", "abcba", "abcdcba"):
+ <pre>
+   ^(.|(.)(?1)\2)$
+ </pre>
+ The idea is that it either matches a single character, or two identical
+ characters surrounding a sub-palindrome. In Perl, this pattern works; in PCRE
+ it does not if the pattern is longer than three characters. Consider the
+ subject string "abcba":
+ </P>
+ <P>
+ At the top level, the first character is matched, but as it is not at the end
+ of the string, the first alternative fails; the second alternative is taken
+ and the recursion kicks in. The recursive call to subpattern 1 successfully
+ matches the next character ("b"). (Note that the beginning and end of line
+ tests are not part of the recursion).
+ </P>
+ <P>
+ Back at the top level, the next character ("c") is compared with what
+ subpattern 2 matched, which was "a". This fails. Because the recursion is
+ treated as an atomic group, there are now no backtracking points, and so the
+ entire match fails. (Perl is able, at this point, to re-enter the recursion and
+ try the second alternative.) However, if the pattern is written with the
+ alternatives in the other order, things are different:
+ <pre>
+   ^((.)(?1)\2|.)$
+ </pre>
+ This time, the recursing alternative is tried first, and continues to recurse
+ until it runs out of characters, at which point the recursion fails. But this
+ time we do have another alternative to try at the higher level. That is the big
+ difference: in the previous case the remaining alternative is at a deeper
+ recursion level, which PCRE cannot use.
+ </P>
+ <P>
+ To change the pattern so that matches all palindromic strings, not just those
+ with an odd number of characters, it is tempting to change the pattern to this:
+ <pre>
+   ^((.)(?1)\2|.?)$
+ </pre>
+ Again, this works in Perl, but not in PCRE, and for the same reason. When a
+ deeper recursion has matched a single character, it cannot be entered again in
+ order to match an empty string. The solution is to separate the two cases, and
+ write out the odd and even cases as alternatives at the higher level:
+ <pre>
+   ^(?:((.)(?1)\2|)|((.)(?3)\4|.))
+ </pre>
+ If you want to match typical palindromic phrases, the pattern has to ignore all
+ non-word characters, which can be done like this:
+ <pre>
+   ^\W*+(?:((.)\W*+(?1)\W*+\2|)|((.)\W*+(?3)\W*+\4|\W*+.\W*+))\W*+$
+ </pre>
+ If run with the PCRE_CASELESS option, this pattern matches phrases such as "A
+ man, a plan, a canal: Panama!" and it works well in both PCRE and Perl. Note
+ the use of the possessive quantifier *+ to avoid backtracking into sequences of
+ non-word characters. Without this, PCRE takes a great deal longer (ten times or
+ more) to match typical phrases, and Perl takes so long that you think it has
+ gone into a loop.
  <a name="subpatternsassubroutines"></a></P>
  <br><a name="SEC22" href="#TOC1">SUBPATTERNS AS SUBROUTINES</a><br>
  <P>
-Line 2138 
 failing negative assertion, they cause a
+Line 2198 
 failing negative assertion, they cause a
  <b>pcre_dfa_exec()</b>.
  </P>
  <P>
+ If any of these verbs are used in an assertion subpattern, their effect is
+ confined to that subpattern; it does not extend to the surrounding pattern.
+ Note that assertion subpatterns are processed as anchored at the point where
+ they are tested.
+ </P>
+ <P>
  The new verbs make use of what was previously invalid syntax: an opening
  parenthesis followed by an asterisk. In Perl, they are generally of the form
  (*VERB:ARG) but PCRE does not support the use of arguments, so its general
-Line 2154 
 The following verbs act as soon as they
+Line 2220 
 The following verbs act as soon as they
  </pre>
  This verb causes the match to end successfully, skipping the remainder of the
  pattern. When inside a recursion, only the innermost pattern is ended
- immediately. PCRE differs from Perl in what happens if the (*ACCEPT) is inside
+ immediately. If the (*ACCEPT) is inside capturing parentheses, the data so far
- capturing parentheses. In Perl, the data so far is captured: in PCRE no data is
+ is captured. (This feature was added to PCRE at release 8.00.) For example:
- captured. For example:
  <pre>
-   A(A|B(*ACCEPT)|C)D
+   A((?:A|B(*ACCEPT)|C)D)
  </pre>
- This matches "AB", "AAD", or "ACD", but when it matches "AB", no data is
+ This matches "AB", "AAD", or "ACD"; when it matches "AB", "B" is captured by
- captured.
+ the outer parentheses.
  <pre>
    (*FAIL) or (*F)
  </pre>
-Line 2253 
 Cambridge CB2 3QH, England.
+Line 2318 
 Cambridge CB2 3QH, England.
  </P>
  <br><a name="SEC28" href="#TOC1">REVISION</a><br>
  <P>
- Last updated: 11 April 2009
+ Last updated: 18 September 2009
  <br>
  Copyright &copy; 1997-2009 University of Cambridge.
  <br>

 Legend:



Removed from v.452
 


changed lines


 
Added in v.453
 Legend:



Removed from v.452
 


changed lines


 
Added in v.453
-Removed from v.452
+Added in v.453

webmaster@exim.org	ViewVC Help
Powered by ViewVC 1.1.12