| 1 |
Technical Notes about PCRE |
Technical Notes about PCRE |
| 2 |
-------------------------- |
-------------------------- |
| 3 |
|
|
| 4 |
|
These are very rough technical notes that record potentially useful information |
| 5 |
|
about PCRE internals. |
| 6 |
|
|
| 7 |
Historical note 1 |
Historical note 1 |
| 8 |
----------------- |
----------------- |
| 9 |
|
|
| 16 |
Perl code does, but instead checked all possibilities simultaneously by keeping |
Perl code does, but instead checked all possibilities simultaneously by keeping |
| 17 |
a list of current states and checking all of them as it advanced through the |
a list of current states and checking all of them as it advanced through the |
| 18 |
subject string. In the terminology of Jeffrey Friedl's book, it was a "DFA |
subject string. In the terminology of Jeffrey Friedl's book, it was a "DFA |
| 19 |
algorithm". When the pattern was all used up, all remaining states were |
algorithm", though it was not a traditional Finite State Machine (FSM). When |
| 20 |
possible matches, and the one matching the longest subset of the subject string |
the pattern was all used up, all remaining states were possible matches, and |
| 21 |
was chosen. This did not necessarily maximize the individual wild portions of |
the one matching the longest subset of the subject string was chosen. This did |
| 22 |
the pattern, as is expected in Unix and Perl-style regular expressions. |
not necessarily maximize the individual wild portions of the pattern, as is |
| 23 |
|
expected in Unix and Perl-style regular expressions. |
| 24 |
|
|
| 25 |
Historical note 2 |
Historical note 2 |
| 26 |
----------------- |
----------------- |
| 27 |
|
|
| 28 |
By contrast, the code originally written by Henry Spencer and subsequently |
By contrast, the code originally written by Henry Spencer (which was |
| 29 |
heavily modified for Perl actually compiles the expression twice: once in a |
subsequently heavily modified for Perl) compiles the expression twice: once in |
| 30 |
dummy mode in order to find out how much store will be needed, and then for |
a dummy mode in order to find out how much store will be needed, and then for |
| 31 |
real. The execution function operates by backtracking and maximizing (or, |
real. (The Perl version probably doesn't do this any more; I'm talking about |
| 32 |
optionally, minimizing in Perl) the amount of the subject that matches |
the original library.) The execution function operates by backtracking and |
| 33 |
individual wild portions of the pattern. This is an "NFA algorithm" in Friedl's |
maximizing (or, optionally, minimizing in Perl) the amount of the subject that |
| 34 |
terminology. |
matches individual wild portions of the pattern. This is an "NFA algorithm" in |
| 35 |
|
Friedl's terminology. |
| 36 |
|
|
| 37 |
OK, here's the real stuff |
OK, here's the real stuff |
| 38 |
------------------------- |
------------------------- |
| 39 |
|
|
| 40 |
For the set of functions that forms PCRE (which are unrelated to those |
For the set of functions that form the "basic" PCRE library (which are |
| 41 |
mentioned above), I tried at first to invent an algorithm that used an amount |
unrelated to those mentioned above), I tried at first to invent an algorithm |
| 42 |
of store bounded by a multiple of the number of characters in the pattern, to |
that used an amount of store bounded by a multiple of the number of characters |
| 43 |
save on compiling time. However, because of the greater complexity in Perl |
in the pattern, to save on compiling time. However, because of the greater |
| 44 |
regular expressions, I couldn't do this. In any case, a first pass through the |
complexity in Perl regular expressions, I couldn't do this. In any case, a |
| 45 |
pattern is needed, for a number of reasons. PCRE works by running a very |
first pass through the pattern is helpful for other reasons. |
| 46 |
degenerate first pass to calculate a maximum store size, and then a second pass |
|
| 47 |
to do the real compile - which may use a bit less than the predicted amount of |
Computing the memory requirement: how it was |
| 48 |
store. The idea is that this is going to turn out faster because the first pass |
-------------------------------------------- |
| 49 |
is degenerate and the second pass can just store stuff straight into the |
|
| 50 |
vector. It does make the compiling functions bigger, of course, but they have |
Up to and including release 6.7, PCRE worked by running a very degenerate first |
| 51 |
got quite big anyway to handle all the Perl stuff. |
pass to calculate a maximum store size, and then a second pass to do the real |
| 52 |
|
compile - which might use a bit less than the predicted amount of memory. The |
| 53 |
|
idea was that this would turn out faster than the Henry Spencer code because |
| 54 |
|
the first pass is degenerate and the second pass can just store stuff straight |
| 55 |
|
into the vector, which it knows is big enough. |
| 56 |
|
|
| 57 |
|
Computing the memory requirement: how it is |
| 58 |
|
------------------------------------------- |
| 59 |
|
|
| 60 |
|
By the time I was working on a potential 6.8 release, the degenerate first pass |
| 61 |
|
had become very complicated and hard to maintain. Indeed one of the early |
| 62 |
|
things I did for 6.8 was to fix Yet Another Bug in the memory computation. Then |
| 63 |
|
I had a flash of inspiration as to how I could run the real compile function in |
| 64 |
|
a "fake" mode that enables it to compute how much memory it would need, while |
| 65 |
|
actually only ever using a few hundred bytes of working memory, and without too |
| 66 |
|
many tests of the mode that might slow it down. So I re-factored the compiling |
| 67 |
|
functions to work this way. This got rid of about 600 lines of source. It |
| 68 |
|
should make future maintenance and development easier. As this was such a major |
| 69 |
|
change, I never released 6.8, instead upping the number to 7.0 (other quite |
| 70 |
|
major changes are also present in the 7.0 release). |
| 71 |
|
|
| 72 |
|
A side effect of this work is that the previous limit of 200 on the nesting |
| 73 |
|
depth of parentheses was removed. However, there is a downside: pcre_compile() |
| 74 |
|
runs more slowly than before (30% or more, depending on the pattern) because it |
| 75 |
|
is doing a full analysis of the pattern. My hope is that this is not a big |
| 76 |
|
issue. |
| 77 |
|
|
| 78 |
|
Traditional matching function |
| 79 |
|
----------------------------- |
| 80 |
|
|
| 81 |
|
The "traditional", and original, matching function is called pcre_exec(), and |
| 82 |
|
it implements an NFA algorithm, similar to the original Henry Spencer algorithm |
| 83 |
|
and the way that Perl works. Not surprising, since it is intended to be as |
| 84 |
|
compatible with Perl as possible. This is the function most users of PCRE will |
| 85 |
|
use most of the time. |
| 86 |
|
|
| 87 |
|
Supplementary matching function |
| 88 |
|
------------------------------- |
| 89 |
|
|
| 90 |
|
From PCRE 6.0, there is also a supplementary matching function called |
| 91 |
|
pcre_dfa_exec(). This implements a DFA matching algorithm that searches |
| 92 |
|
simultaneously for all possible matches that start at one point in the subject |
| 93 |
|
string. (Going back to my roots: see Historical Note 1 above.) This function |
| 94 |
|
intreprets the same compiled pattern data as pcre_exec(); however, not all the |
| 95 |
|
facilities are available, and those that are do not always work in quite the |
| 96 |
|
same way. See the user documentation for details. |
| 97 |
|
|
| 98 |
|
The algorithm that is used for pcre_dfa_exec() is not a traditional FSM, |
| 99 |
|
because it may have a number of states active at one time. More work would be |
| 100 |
|
needed at compile time to produce a traditional FSM where only one state is |
| 101 |
|
ever active at once. I believe some other regex matchers work this way. |
| 102 |
|
|
| 103 |
|
|
| 104 |
|
Format of compiled patterns |
| 105 |
|
--------------------------- |
| 106 |
|
|
| 107 |
The compiled form of a pattern is a vector of bytes, containing items of |
The compiled form of a pattern is a vector of bytes, containing items of |
| 108 |
variable length. The first byte in an item is an opcode, and the length of the |
variable length. The first byte in an item is an opcode, and the length of the |
| 110 |
follow it. |
follow it. |
| 111 |
|
|
| 112 |
In many cases below "two-byte" data values are specified. This is in fact just |
In many cases below "two-byte" data values are specified. This is in fact just |
| 113 |
a default. PCRE can be compiled to use 3-byte or 4-byte values (impairing the |
a default when the number is an offset within the compiled pattern. PCRE can be |
| 114 |
|
compiled to use 3-byte or 4-byte values for these offsets (impairing the |
| 115 |
performance). This is necessary only when patterns whose compiled length is |
performance). This is necessary only when patterns whose compiled length is |
| 116 |
greater than 64K are going to be processed. In this description, we assume the |
greater than 64K are going to be processed. In this description, we assume the |
| 117 |
"normal" compilation options. |
"normal" compilation options. "Two-byte" data values that are counts (e.g. for |
| 118 |
|
quantifiers) are always just two bytes. |
| 119 |
|
|
| 120 |
A list of all the opcodes follows: |
A list of all the opcodes follows: |
| 121 |
|
|
| 142 |
OP_EOD match end of data: \z |
OP_EOD match end of data: \z |
| 143 |
OP_DOLL $ (end of data, or before \n in multiline) |
OP_DOLL $ (end of data, or before \n in multiline) |
| 144 |
OP_EXTUNI match an extended Unicode character |
OP_EXTUNI match an extended Unicode character |
| 145 |
|
OP_ANYNL match any Unicode newline sequence |
| 146 |
|
|
| 147 |
|
|
| 148 |
Repeating single characters |
Repeating single characters |
| 153 |
|
|
| 154 |
OP_STAR |
OP_STAR |
| 155 |
OP_MINSTAR |
OP_MINSTAR |
| 156 |
|
OP_POSSTAR |
| 157 |
OP_PLUS |
OP_PLUS |
| 158 |
OP_MINPLUS |
OP_MINPLUS |
| 159 |
|
OP_POSPLUS |
| 160 |
OP_QUERY |
OP_QUERY |
| 161 |
OP_MINQUERY |
OP_MINQUERY |
| 162 |
|
OP_POSQUERY |
| 163 |
|
|
| 164 |
In ASCII mode, these are two-byte items; in UTF-8 mode, the length is variable. |
In ASCII mode, these are two-byte items; in UTF-8 mode, the length is variable. |
| 165 |
Those with "MIN" in their name are the minimizing versions. Each is followed by |
Those with "MIN" in their name are the minimizing versions. Those with "POS" in |
| 166 |
the character that is to be repeated. Other repeats make use of |
their names are possessive versions. Each is followed by the character that is |
| 167 |
|
to be repeated. Other repeats make use of |
| 168 |
|
|
| 169 |
OP_UPTO |
OP_UPTO |
| 170 |
OP_MINUPTO |
OP_MINUPTO |
| 171 |
|
OP_POSUPTO |
| 172 |
OP_EXACT |
OP_EXACT |
| 173 |
|
|
| 174 |
which are followed by a two-byte count (most significant first) and the |
which are followed by a two-byte count (most significant first) and the |
| 175 |
repeated character. OP_UPTO matches from 0 to the given number. A repeat with a |
repeated character. OP_UPTO matches from 0 to the given number. A repeat with a |
| 176 |
non-zero minimum and a fixed maximum is coded as an OP_EXACT followed by an |
non-zero minimum and a fixed maximum is coded as an OP_EXACT followed by an |
| 177 |
OP_UPTO (or OP_MINUPTO). |
OP_UPTO (or OP_MINUPTO or OPT_POSUPTO). |
| 178 |
|
|
| 179 |
|
|
| 180 |
Repeating character types |
Repeating character types |
| 186 |
|
|
| 187 |
OP_TYPESTAR |
OP_TYPESTAR |
| 188 |
OP_TYPEMINSTAR |
OP_TYPEMINSTAR |
| 189 |
|
OP_TYPEPOSSTAR |
| 190 |
OP_TYPEPLUS |
OP_TYPEPLUS |
| 191 |
OP_TYPEMINPLUS |
OP_TYPEMINPLUS |
| 192 |
|
OP_TYPEPOSPLUS |
| 193 |
OP_TYPEQUERY |
OP_TYPEQUERY |
| 194 |
OP_TYPEMINQUERY |
OP_TYPEMINQUERY |
| 195 |
|
OP_TYPEPOSQUERY |
| 196 |
OP_TYPEUPTO |
OP_TYPEUPTO |
| 197 |
OP_TYPEMINUPTO |
OP_TYPEMINUPTO |
| 198 |
|
OP_TYPEPOSUPTO |
| 199 |
OP_TYPEEXACT |
OP_TYPEEXACT |
| 200 |
|
|
| 201 |
|
|
| 204 |
|
|
| 205 |
OP_PROP and OP_NOTPROP are used for positive and negative matches of a |
OP_PROP and OP_NOTPROP are used for positive and negative matches of a |
| 206 |
character by testing its Unicode property (the \p and \P escape sequences). |
character by testing its Unicode property (the \p and \P escape sequences). |
| 207 |
Each is followed by a single byte that encodes the desired property value. |
Each is followed by two bytes that encode the desired property as a type and a |
| 208 |
|
value. |
| 209 |
|
|
| 210 |
Repeats of these items use the OP_TYPESTAR etc. set of opcodes, followed by two |
Repeats of these items use the OP_TYPESTAR etc. set of opcodes, followed by |
| 211 |
bytes: OP_PROP or OP_NOTPROP and then the desired property value. |
three bytes: OP_PROP or OP_NOTPROP and then the desired property type and |
| 212 |
|
value. |
| 213 |
|
|
| 214 |
|
|
| 215 |
Matching literal characters |
Matching literal characters |
| 259 |
Repeating character classes and back references |
Repeating character classes and back references |
| 260 |
----------------------------------------------- |
----------------------------------------------- |
| 261 |
|
|
| 262 |
Single-character classes are handled specially (see above). This applies to |
Single-character classes are handled specially (see above). This section |
| 263 |
OP_CLASS and OP_REF. In both cases, the repeat information follows the base |
applies to OP_CLASS and OP_REF. In both cases, the repeat information follows |
| 264 |
item. The matching code looks at the following opcode to see if it is one of |
the base item. The matching code looks at the following opcode to see if it is |
| 265 |
|
one of |
| 266 |
|
|
| 267 |
OP_CRSTAR |
OP_CRSTAR |
| 268 |
OP_CRMINSTAR |
OP_CRMINSTAR |
| 274 |
OP_CRMINRANGE |
OP_CRMINRANGE |
| 275 |
|
|
| 276 |
All but the last two are just single-byte items. The others are followed by |
All but the last two are just single-byte items. The others are followed by |
| 277 |
four bytes of data, comprising the minimum and maximum repeat counts. |
four bytes of data, comprising the minimum and maximum repeat counts. There are |
| 278 |
|
no special possessive opcodes for these repeats; a possessive repeat is |
| 279 |
|
compiled into an atomic group. |
| 280 |
|
|
| 281 |
|
|
| 282 |
Brackets and alternation |
Brackets and alternation |
| 285 |
A pair of non-capturing (round) brackets is wrapped round each expression at |
A pair of non-capturing (round) brackets is wrapped round each expression at |
| 286 |
compile time, so alternation always happens in the context of brackets. |
compile time, so alternation always happens in the context of brackets. |
| 287 |
|
|
| 288 |
Non-capturing brackets use the opcode OP_BRA, while capturing brackets use |
[Note for North Americans: "bracket" to some English speakers, including |
| 289 |
OP_BRA+1, OP_BRA+2, etc. [Note for North Americans: "bracket" to some English |
myself, can be round, square, curly, or pointy. Hence this usage.] |
| 290 |
speakers, including myself, can be round, square, curly, or pointy. Hence this |
|
| 291 |
usage.] |
Non-capturing brackets use the opcode OP_BRA. Originally PCRE was limited to 99 |
| 292 |
|
capturing brackets and it used a different opcode for each one. From release |
| 293 |
Originally PCRE was limited to 99 capturing brackets (so as not to use up all |
3.5, the limit was removed by putting the bracket number into the data for |
| 294 |
the opcodes). From release 3.5, there is no limit. What happens is that the |
higher-numbered brackets. From release 7.0 all capturing brackets are handled |
| 295 |
first ones, up to EXTRACT_BASIC_MAX are handled with separate opcodes, as |
this way, using the single opcode OP_CBRA. |
| 296 |
above. If there are more, the opcode is set to EXTRACT_BASIC_MAX+1, and the |
|
| 297 |
first operation in the bracket is OP_BRANUMBER, followed by a 2-byte bracket |
A bracket opcode is followed by LINK_SIZE bytes which give the offset to the |
| 298 |
number. This opcode is ignored while matching, but is fished out when handling |
next alternative OP_ALT or, if there aren't any branches, to the matching |
| 299 |
the bracket itself. (They could have all been done like this, but I was making |
OP_KET opcode. Each OP_ALT is followed by LINK_SIZE bytes giving the offset to |
| 300 |
minimal changes.) |
the next one, or to the OP_KET opcode. For capturing brackets, the bracket |
| 301 |
|
number immediately follows the offset, always as a 2-byte item. |
|
A bracket opcode is followed by two bytes which give the offset to the next |
|
|
alternative OP_ALT or, if there aren't any branches, to the matching OP_KET |
|
|
opcode. Each OP_ALT is followed by two bytes giving the offset to the next one, |
|
|
or to the OP_KET opcode. |
|
| 302 |
|
|
| 303 |
OP_KET is used for subpatterns that do not repeat indefinitely, while |
OP_KET is used for subpatterns that do not repeat indefinitely, while |
| 304 |
OP_KETRMIN and OP_KETRMAX are used for indefinite repetitions, minimally or |
OP_KETRMIN and OP_KETRMAX are used for indefinite repetitions, minimally or |
| 305 |
maximally respectively. All three are followed by two bytes giving (as a |
maximally respectively. All three are followed by LINK_SIZE bytes giving (as a |
| 306 |
positive number) the offset back to the matching OP_BRA opcode. |
positive number) the offset back to the matching bracket opcode. |
| 307 |
|
|
| 308 |
If a subpattern is quantified such that it is permitted to match zero times, it |
If a subpattern is quantified such that it is permitted to match zero times, it |
| 309 |
is preceded by one of OP_BRAZERO or OP_BRAMINZERO. These are single-byte |
is preceded by one of OP_BRAZERO or OP_BRAMINZERO. These are single-byte |
| 318 |
A subpattern with a bounded maximum repetition is replicated in a nested |
A subpattern with a bounded maximum repetition is replicated in a nested |
| 319 |
fashion up to the maximum number of times, with OP_BRAZERO or OP_BRAMINZERO |
fashion up to the maximum number of times, with OP_BRAZERO or OP_BRAMINZERO |
| 320 |
before each replication after the minimum, so that, for example, (abc){2,5} is |
before each replication after the minimum, so that, for example, (abc){2,5} is |
| 321 |
compiled as (abc)(abc)((abc)((abc)(abc)?)?)?. |
compiled as (abc)(abc)((abc)((abc)(abc)?)?)?, except that each bracketed group |
| 322 |
|
has the same number. |
| 323 |
|
|
| 324 |
|
When a repeated subpattern has an unbounded upper limit, it is checked to see |
| 325 |
|
whether it could match an empty string. If this is the case, the opcode in the |
| 326 |
|
final replication is changed to OP_SBRA or OP_SCBRA. This tells the matcher |
| 327 |
|
that it needs to check for matching an empty string when it hits OP_KETRMIN or |
| 328 |
|
OP_KETRMAX, and if so, to break the loop. |
| 329 |
|
|
| 330 |
|
|
| 331 |
Assertions |
Assertions |
| 341 |
fixed lengths. |
fixed lengths. |
| 342 |
|
|
| 343 |
|
|
| 344 |
Once-only subpatterns |
Once-only (atomic) subpatterns |
| 345 |
--------------------- |
------------------------------ |
| 346 |
|
|
| 347 |
These are also just like other subpatterns, but they start with the opcode |
These are also just like other subpatterns, but they start with the opcode |
| 348 |
OP_ONCE. |
OP_ONCE. The check for matching an empty string in an unbounded repeat is |
| 349 |
|
handled entirely at runtime, so there is just this one opcode. |
| 350 |
|
|
| 351 |
|
|
| 352 |
Conditional subpatterns |
Conditional subpatterns |
| 353 |
----------------------- |
----------------------- |
| 354 |
|
|
| 355 |
These are like other subpatterns, but they start with the opcode OP_COND. If |
These are like other subpatterns, but they start with the opcode OP_COND, or |
| 356 |
|
OP_SCOND for one that might match an empty string in an unbounded repeat. If |
| 357 |
the condition is a back reference, this is stored at the start of the |
the condition is a back reference, this is stored at the start of the |
| 358 |
subpattern using the opcode OP_CREF followed by two bytes containing the |
subpattern using the opcode OP_CREF followed by two bytes containing the |
| 359 |
reference number. If the condition is "in recursion" (coded as "(?(R)"), the |
reference number. If the condition is "in recursion" (coded as "(?(R)"), or "in |
| 360 |
same scheme is used, with a "reference number" of 0xffff. Otherwise, a |
recursion of group x" (coded as "(?(Rx)"), the group number is stored at the |
| 361 |
conditional subpattern always starts with one of the assertions. |
start of the subpattern using the opcode OP_RREF, and a value of zero for "the |
| 362 |
|
whole pattern". For a DEFINE condition, just the single byte OP_DEF is used (it |
| 363 |
|
has no associated data). Otherwise, a conditional subpattern always starts with |
| 364 |
|
one of the assertions. |
| 365 |
|
|
| 366 |
|
|
| 367 |
Recursion |
Recursion |
| 369 |
|
|
| 370 |
Recursion either matches the current regex, or some subexpression. The opcode |
Recursion either matches the current regex, or some subexpression. The opcode |
| 371 |
OP_RECURSE is followed by an value which is the offset to the starting bracket |
OP_RECURSE is followed by an value which is the offset to the starting bracket |
| 372 |
from the start of the whole pattern. |
from the start of the whole pattern. From release 6.5, OP_RECURSE is |
| 373 |
|
automatically wrapped inside OP_ONCE brackets (because otherwise some patterns |
| 374 |
|
broke it). OP_RECURSE is also used for "subroutine" calls, even though they |
| 375 |
|
are not strictly a recursion. |
| 376 |
|
|
| 377 |
|
|
| 378 |
Callout |
Callout |
| 399 |
data. |
data. |
| 400 |
|
|
| 401 |
Philip Hazel |
Philip Hazel |
| 402 |
September 2004 |
November 2006 |