Annotation of embedaddon/pcre/doc/html/pcrematching.html, revision 1.1.1.2
1.1 misho 1: <html>
2: <head>
3: <title>pcrematching specification</title>
4: </head>
5: <body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
6: <h1>pcrematching man page</h1>
7: <p>
8: Return to the <a href="index.html">PCRE index page</a>.
9: </p>
10: <p>
11: This page is part of the PCRE HTML documentation. It was generated automatically
12: from the original man page. If there is any nonsense in it, please consult the
13: man page, in case the conversion went wrong.
14: <br>
15: <ul>
16: <li><a name="TOC1" href="#SEC1">PCRE MATCHING ALGORITHMS</a>
17: <li><a name="TOC2" href="#SEC2">REGULAR EXPRESSIONS AS TREES</a>
18: <li><a name="TOC3" href="#SEC3">THE STANDARD MATCHING ALGORITHM</a>
19: <li><a name="TOC4" href="#SEC4">THE ALTERNATIVE MATCHING ALGORITHM</a>
20: <li><a name="TOC5" href="#SEC5">ADVANTAGES OF THE ALTERNATIVE ALGORITHM</a>
21: <li><a name="TOC6" href="#SEC6">DISADVANTAGES OF THE ALTERNATIVE ALGORITHM</a>
22: <li><a name="TOC7" href="#SEC7">AUTHOR</a>
23: <li><a name="TOC8" href="#SEC8">REVISION</a>
24: </ul>
25: <br><a name="SEC1" href="#TOC1">PCRE MATCHING ALGORITHMS</a><br>
26: <P>
27: This document describes the two different algorithms that are available in PCRE
28: for matching a compiled regular expression against a given subject string. The
1.1.1.2 ! misho 29: "standard" algorithm is the one provided by the <b>pcre_exec()</b> and
! 30: <b>pcre16_exec()</b> functions. These work in the same was as Perl's matching
! 31: function, and provide a Perl-compatible matching operation. The just-in-time
! 32: (JIT) optimization that is described in the
! 33: <a href="pcrejit.html"><b>pcrejit</b></a>
! 34: documentation is compatible with these functions.
1.1 misho 35: </P>
36: <P>
1.1.1.2 ! misho 37: An alternative algorithm is provided by the <b>pcre_dfa_exec()</b> and
! 38: <b>pcre16_dfa_exec()</b> functions; they operate in a different way, and are not
! 39: Perl-compatible. This alternative has advantages and disadvantages compared
! 40: with the standard algorithm, and these are described below.
1.1 misho 41: </P>
42: <P>
43: When there is only one possible way in which a given subject string can match a
44: pattern, the two algorithms give the same answer. A difference arises, however,
45: when there are multiple possibilities. For example, if the pattern
46: <pre>
47: ^<.*>
48: </pre>
49: is matched against the string
50: <pre>
51: <something> <something else> <something further>
52: </pre>
53: there are three possible answers. The standard algorithm finds only one of
54: them, whereas the alternative algorithm finds all three.
55: </P>
56: <br><a name="SEC2" href="#TOC1">REGULAR EXPRESSIONS AS TREES</a><br>
57: <P>
58: The set of strings that are matched by a regular expression can be represented
59: as a tree structure. An unlimited repetition in the pattern makes the tree of
60: infinite size, but it is still a tree. Matching the pattern to a given subject
61: string (from a given starting point) can be thought of as a search of the tree.
62: There are two ways to search a tree: depth-first and breadth-first, and these
63: correspond to the two matching algorithms provided by PCRE.
64: </P>
65: <br><a name="SEC3" href="#TOC1">THE STANDARD MATCHING ALGORITHM</a><br>
66: <P>
67: In the terminology of Jeffrey Friedl's book "Mastering Regular
68: Expressions", the standard algorithm is an "NFA algorithm". It conducts a
69: depth-first search of the pattern tree. That is, it proceeds along a single
70: path through the tree, checking that the subject matches what is required. When
71: there is a mismatch, the algorithm tries any alternatives at the current point,
72: and if they all fail, it backs up to the previous branch point in the tree, and
73: tries the next alternative branch at that level. This often involves backing up
74: (moving to the left) in the subject string as well. The order in which
75: repetition branches are tried is controlled by the greedy or ungreedy nature of
76: the quantifier.
77: </P>
78: <P>
79: If a leaf node is reached, a matching string has been found, and at that point
80: the algorithm stops. Thus, if there is more than one possible match, this
81: algorithm returns the first one that it finds. Whether this is the shortest,
82: the longest, or some intermediate length depends on the way the greedy and
83: ungreedy repetition quantifiers are specified in the pattern.
84: </P>
85: <P>
86: Because it ends up with a single path through the tree, it is relatively
87: straightforward for this algorithm to keep track of the substrings that are
88: matched by portions of the pattern in parentheses. This provides support for
89: capturing parentheses and back references.
90: </P>
91: <br><a name="SEC4" href="#TOC1">THE ALTERNATIVE MATCHING ALGORITHM</a><br>
92: <P>
93: This algorithm conducts a breadth-first search of the tree. Starting from the
94: first matching point in the subject, it scans the subject string from left to
95: right, once, character by character, and as it does this, it remembers all the
96: paths through the tree that represent valid matches. In Friedl's terminology,
97: this is a kind of "DFA algorithm", though it is not implemented as a
98: traditional finite state machine (it keeps multiple states active
99: simultaneously).
100: </P>
101: <P>
102: Although the general principle of this matching algorithm is that it scans the
103: subject string only once, without backtracking, there is one exception: when a
104: lookaround assertion is encountered, the characters following or preceding the
105: current point have to be independently inspected.
106: </P>
107: <P>
108: The scan continues until either the end of the subject is reached, or there are
109: no more unterminated paths. At this point, terminated paths represent the
110: different matching possibilities (if there are none, the match has failed).
111: Thus, if there is more than one possible match, this algorithm finds all of
112: them, and in particular, it finds the longest. The matches are returned in
113: decreasing order of length. There is an option to stop the algorithm after the
114: first match (which is necessarily the shortest) is found.
115: </P>
116: <P>
117: Note that all the matches that are found start at the same point in the
118: subject. If the pattern
119: <pre>
120: cat(er(pillar)?)?
121: </pre>
122: is matched against the string "the caterpillar catchment", the result will be
123: the three strings "caterpillar", "cater", and "cat" that start at the fifth
124: character of the subject. The algorithm does not automatically move on to find
125: matches that start at later positions.
126: </P>
127: <P>
128: There are a number of features of PCRE regular expressions that are not
129: supported by the alternative matching algorithm. They are as follows:
130: </P>
131: <P>
132: 1. Because the algorithm finds all possible matches, the greedy or ungreedy
133: nature of repetition quantifiers is not relevant. Greedy and ungreedy
134: quantifiers are treated in exactly the same way. However, possessive
135: quantifiers can make a difference when what follows could also match what is
136: quantified, for example in a pattern like this:
137: <pre>
138: ^a++\w!
139: </pre>
140: This pattern matches "aaab!" but not "aaa!", which would be matched by a
141: non-possessive quantifier. Similarly, if an atomic group is present, it is
142: matched as if it were a standalone pattern at the current point, and the
143: longest match is then "locked in" for the rest of the overall pattern.
144: </P>
145: <P>
146: 2. When dealing with multiple paths through the tree simultaneously, it is not
147: straightforward to keep track of captured substrings for the different matching
148: possibilities, and PCRE's implementation of this algorithm does not attempt to
149: do this. This means that no captured substrings are available.
150: </P>
151: <P>
152: 3. Because no substrings are captured, back references within the pattern are
153: not supported, and cause errors if encountered.
154: </P>
155: <P>
156: 4. For the same reason, conditional expressions that use a backreference as the
157: condition or test for a specific group recursion are not supported.
158: </P>
159: <P>
160: 5. Because many paths through the tree may be active, the \K escape sequence,
161: which resets the start of the match when encountered (but may be on some paths
162: and not on others), is not supported. It causes an error if encountered.
163: </P>
164: <P>
165: 6. Callouts are supported, but the value of the <i>capture_top</i> field is
166: always 1, and the value of the <i>capture_last</i> field is always -1.
167: </P>
168: <P>
1.1.1.2 ! misho 169: 7. The \C escape sequence, which (in the standard algorithm) always matches a
! 170: single data unit, even in UTF-8 or UTF-16 modes, is not supported in these
! 171: modes, because the alternative algorithm moves through the subject string one
! 172: character (not data unit) at a time, for all active paths through the tree.
1.1 misho 173: </P>
174: <P>
175: 8. Except for (*FAIL), the backtracking control verbs such as (*PRUNE) are not
176: supported. (*FAIL) is supported, and behaves like a failing negative assertion.
177: </P>
178: <br><a name="SEC5" href="#TOC1">ADVANTAGES OF THE ALTERNATIVE ALGORITHM</a><br>
179: <P>
180: Using the alternative matching algorithm provides the following advantages:
181: </P>
182: <P>
183: 1. All possible matches (at a single point in the subject) are automatically
184: found, and in particular, the longest match is found. To find more than one
185: match using the standard algorithm, you have to do kludgy things with
186: callouts.
187: </P>
188: <P>
189: 2. Because the alternative algorithm scans the subject string just once, and
1.1.1.2 ! misho 190: never needs to backtrack (except for lookbehinds), it is possible to pass very
! 191: long subject strings to the matching function in several pieces, checking for
! 192: partial matching each time. Although it is possible to do multi-segment
! 193: matching using the standard algorithm by retaining partially matched
! 194: substrings, it is more complicated. The
1.1 misho 195: <a href="pcrepartial.html"><b>pcrepartial</b></a>
196: documentation gives details of partial matching and discusses multi-segment
197: matching.
198: </P>
199: <br><a name="SEC6" href="#TOC1">DISADVANTAGES OF THE ALTERNATIVE ALGORITHM</a><br>
200: <P>
201: The alternative algorithm suffers from a number of disadvantages:
202: </P>
203: <P>
204: 1. It is substantially slower than the standard algorithm. This is partly
205: because it has to search for all possible matches, but is also because it is
206: less susceptible to optimization.
207: </P>
208: <P>
209: 2. Capturing parentheses and back references are not supported.
210: </P>
211: <P>
212: 3. Although atomic groups are supported, their use does not provide the
213: performance advantage that it does for the standard algorithm.
214: </P>
215: <br><a name="SEC7" href="#TOC1">AUTHOR</a><br>
216: <P>
217: Philip Hazel
218: <br>
219: University Computing Service
220: <br>
221: Cambridge CB2 3QH, England.
222: <br>
223: </P>
224: <br><a name="SEC8" href="#TOC1">REVISION</a><br>
225: <P>
1.1.1.2 ! misho 226: Last updated: 08 January 2012
1.1 misho 227: <br>
1.1.1.2 ! misho 228: Copyright © 1997-2012 University of Cambridge.
1.1 misho 229: <br>
230: <p>
231: Return to the <a href="index.html">PCRE index page</a>.
232: </p>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to pcrematching.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / pcre / doc / html