diff options
Diffstat (limited to 'ext/pcre/pcrelib/doc/pcre.txt')
| -rw-r--r-- | ext/pcre/pcrelib/doc/pcre.txt | 2068 |
1 files changed, 1194 insertions, 874 deletions
diff --git a/ext/pcre/pcrelib/doc/pcre.txt b/ext/pcre/pcrelib/doc/pcre.txt index d6c204b574..9c7884998c 100644 --- a/ext/pcre/pcrelib/doc/pcre.txt +++ b/ext/pcre/pcrelib/doc/pcre.txt @@ -18,52 +18,57 @@ INTRODUCTION The PCRE library is a set of functions that implement regular expres- sion pattern matching using the same syntax and semantics as Perl, with - just a few differences. The current implementation of PCRE (release - 6.x) corresponds approximately with Perl 5.8, including support for - UTF-8 encoded strings and Unicode general category properties. However, - this support has to be explicitly enabled; it is not the default. - - In addition to the Perl-compatible matching function, PCRE also con- - tains an alternative matching function that matches the same compiled - patterns in a different way. In certain circumstances, the alternative - function has some advantages. For a discussion of the two matching - algorithms, see the pcrematching page. - - PCRE is written in C and released as a C library. A number of people - have written wrappers and interfaces of various kinds. In particular, - Google Inc. have provided a comprehensive C++ wrapper. This is now + just a few differences. (Certain features that appeared in Python and + PCRE before they appeared in Perl are also available using the Python + syntax.) + + The current implementation of PCRE (release 7.x) corresponds approxi- + mately with Perl 5.10, including support for UTF-8 encoded strings and + Unicode general category properties. However, UTF-8 and Unicode support + has to be explicitly enabled; it is not the default. The Unicode tables + correspond to Unicode release 5.0.0. + + In addition to the Perl-compatible matching function, PCRE contains an + alternative matching function that matches the same compiled patterns + in a different way. In certain circumstances, the alternative function + has some advantages. For a discussion of the two matching algorithms, + see the pcrematching page. + + PCRE is written in C and released as a C library. A number of people + have written wrappers and interfaces of various kinds. In particular, + Google Inc. have provided a comprehensive C++ wrapper. This is now included as part of the PCRE distribution. The pcrecpp page has details - of this interface. Other people's contributions can be found in the + of this interface. Other people's contributions can be found in the Contrib directory at the primary FTP site, which is: ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre - Details of exactly which Perl regular expression features are and are + Details of exactly which Perl regular expression features are and are not supported by PCRE are given in separate documents. See the pcrepat- tern and pcrecompat pages. - Some features of PCRE can be included, excluded, or changed when the - library is built. The pcre_config() function makes it possible for a - client to discover which features are available. The features them- - selves are described in the pcrebuild page. Documentation about build- - ing PCRE for various operating systems can be found in the README file + Some features of PCRE can be included, excluded, or changed when the + library is built. The pcre_config() function makes it possible for a + client to discover which features are available. The features them- + selves are described in the pcrebuild page. Documentation about build- + ing PCRE for various operating systems can be found in the README file in the source distribution. - The library contains a number of undocumented internal functions and - data tables that are used by more than one of the exported external - functions, but which are not intended for use by external callers. - Their names all begin with "_pcre_", which hopefully will not provoke + The library contains a number of undocumented internal functions and + data tables that are used by more than one of the exported external + functions, but which are not intended for use by external callers. + Their names all begin with "_pcre_", which hopefully will not provoke any name clashes. In some environments, it is possible to control which - external symbols are exported when a shared library is built, and in + external symbols are exported when a shared library is built, and in these cases the undocumented symbols are not exported. USER DOCUMENTATION - The user documentation for PCRE comprises a number of different sec- - tions. In the "man" format, each of these is a separate "man page". In - the HTML format, each is a separate page, linked from the index page. - In the plain text format, all the sections are concatenated, for ease + The user documentation for PCRE comprises a number of different sec- + tions. In the "man" format, each of these is a separate "man page". In + the HTML format, each is a separate page, linked from the index page. + In the plain text format, all the sections are concatenated, for ease of searching. The sections are as follows: pcre this document @@ -84,124 +89,122 @@ USER DOCUMENTATION pcrestack discussion of stack usage pcretest description of the pcretest testing command - In addition, in the "man" and HTML formats, there is a short page for + In addition, in the "man" and HTML formats, there is a short page for each C library function, listing its arguments and results. LIMITATIONS - There are some size limitations in PCRE but it is hoped that they will + There are some size limitations in PCRE but it is hoped that they will never in practice be relevant. - The maximum length of a compiled pattern is 65539 (sic) bytes if PCRE + The maximum length of a compiled pattern is 65539 (sic) bytes if PCRE is compiled with the default internal linkage size of 2. If you want to - process regular expressions that are truly enormous, you can compile - PCRE with an internal linkage size of 3 or 4 (see the README file in - the source distribution and the pcrebuild documentation for details). - In these cases the limit is substantially larger. However, the speed - of execution will be slower. - - All values in repeating quantifiers must be less than 65536. The maxi- - mum compiled length of subpattern with an explicit repeat count is + process regular expressions that are truly enormous, you can compile + PCRE with an internal linkage size of 3 or 4 (see the README file in + the source distribution and the pcrebuild documentation for details). + In these cases the limit is substantially larger. However, the speed + of execution is slower. + + All values in repeating quantifiers must be less than 65536. The maxi- + mum compiled length of subpattern with an explicit repeat count is 30000 bytes. The maximum number of capturing subpatterns is 65535. - There is no limit to the number of non-capturing subpatterns, but the - maximum depth of nesting of all kinds of parenthesized subpattern, - including capturing subpatterns, assertions, and other types of subpat- - tern, is 200. + There is no limit to the number of parenthesized subpatterns, but there + can be no more than 65535 capturing subpatterns. - The maximum length of name for a named subpattern is 32, and the maxi- - mum number of named subpatterns is 10000. + The maximum length of name for a named subpattern is 32 characters, and + the maximum number of named subpatterns is 10000. - The maximum length of a subject string is the largest positive number - that an integer variable can hold. However, when using the traditional + The maximum length of a subject string is the largest positive number + that an integer variable can hold. However, when using the traditional matching function, PCRE uses recursion to handle subpatterns and indef- - inite repetition. This means that the available stack space may limit + inite repetition. This means that the available stack space may limit the size of a subject string that can be processed by certain patterns. For a discussion of stack issues, see the pcrestack documentation. UTF-8 AND UNICODE PROPERTY SUPPORT - From release 3.3, PCRE has had some support for character strings - encoded in the UTF-8 format. For release 4.0 this was greatly extended - to cover most common requirements, and in release 5.0 additional sup- + From release 3.3, PCRE has had some support for character strings + encoded in the UTF-8 format. For release 4.0 this was greatly extended + to cover most common requirements, and in release 5.0 additional sup- port for Unicode general category properties was added. - In order process UTF-8 strings, you must build PCRE to include UTF-8 - support in the code, and, in addition, you must call pcre_compile() - with the PCRE_UTF8 option flag. When you do this, both the pattern and - any subject strings that are matched against it are treated as UTF-8 + In order process UTF-8 strings, you must build PCRE to include UTF-8 + support in the code, and, in addition, you must call pcre_compile() + with the PCRE_UTF8 option flag. When you do this, both the pattern and + any subject strings that are matched against it are treated as UTF-8 strings instead of just strings of bytes. - If you compile PCRE with UTF-8 support, but do not use it at run time, - the library will be a bit bigger, but the additional run time overhead - is limited to testing the PCRE_UTF8 flag in several places, so should - not be very large. + If you compile PCRE with UTF-8 support, but do not use it at run time, + the library will be a bit bigger, but the additional run time overhead + is limited to testing the PCRE_UTF8 flag occasionally, so should not be + very big. If PCRE is built with Unicode character property support (which implies - UTF-8 support), the escape sequences \p{..}, \P{..}, and \X are sup- + UTF-8 support), the escape sequences \p{..}, \P{..}, and \X are sup- ported. The available properties that can be tested are limited to the - general category properties such as Lu for an upper case letter or Nd - for a decimal number, the Unicode script names such as Arabic or Han, - and the derived properties Any and L&. A full list is given in the + general category properties such as Lu for an upper case letter or Nd + for a decimal number, the Unicode script names such as Arabic or Han, + and the derived properties Any and L&. A full list is given in the pcrepattern documentation. Only the short names for properties are sup- - ported. For example, \p{L} matches a letter. Its Perl synonym, \p{Let- - ter}, is not supported. Furthermore, in Perl, many properties may - optionally be prefixed by "Is", for compatibility with Perl 5.6. PCRE + ported. For example, \p{L} matches a letter. Its Perl synonym, \p{Let- + ter}, is not supported. Furthermore, in Perl, many properties may + optionally be prefixed by "Is", for compatibility with Perl 5.6. PCRE does not support this. The following comments apply when PCRE is running in UTF-8 mode: - 1. When you set the PCRE_UTF8 flag, the strings passed as patterns and - subjects are checked for validity on entry to the relevant functions. + 1. When you set the PCRE_UTF8 flag, the strings passed as patterns and + subjects are checked for validity on entry to the relevant functions. If an invalid UTF-8 string is passed, an error return is given. In some - situations, you may already know that your strings are valid, and + situations, you may already know that your strings are valid, and therefore want to skip these checks in order to improve performance. If - you set the PCRE_NO_UTF8_CHECK flag at compile time or at run time, - PCRE assumes that the pattern or subject it is given (respectively) - contains only valid UTF-8 codes. In this case, it does not diagnose an - invalid UTF-8 string. If you pass an invalid UTF-8 string to PCRE when - PCRE_NO_UTF8_CHECK is set, the results are undefined. Your program may + you set the PCRE_NO_UTF8_CHECK flag at compile time or at run time, + PCRE assumes that the pattern or subject it is given (respectively) + contains only valid UTF-8 codes. In this case, it does not diagnose an + invalid UTF-8 string. If you pass an invalid UTF-8 string to PCRE when + PCRE_NO_UTF8_CHECK is set, the results are undefined. Your program may crash. - 2. An unbraced hexadecimal escape sequence (such as \xb3) matches a + 2. An unbraced hexadecimal escape sequence (such as \xb3) matches a two-byte UTF-8 character if the value is greater than 127. - 3. Octal numbers up to \777 are recognized, and match two-byte UTF-8 + 3. Octal numbers up to \777 are recognized, and match two-byte UTF-8 characters for values greater than \177. - 4. Repeat quantifiers apply to complete UTF-8 characters, not to indi- + 4. Repeat quantifiers apply to complete UTF-8 characters, not to indi- vidual bytes, for example: \x{100}{3}. - 5. The dot metacharacter matches one UTF-8 character instead of a sin- + 5. The dot metacharacter matches one UTF-8 character instead of a sin- gle byte. - 6. The escape sequence \C can be used to match a single byte in UTF-8 - mode, but its use can lead to some strange effects. This facility is + 6. The escape sequence \C can be used to match a single byte in UTF-8 + mode, but its use can lead to some strange effects. This facility is not available in the alternative matching function, pcre_dfa_exec(). - 7. The character escapes \b, \B, \d, \D, \s, \S, \w, and \W correctly - test characters of any code value, but the characters that PCRE recog- - nizes as digits, spaces, or word characters remain the same set as + 7. The character escapes \b, \B, \d, \D, \s, \S, \w, and \W correctly + test characters of any code value, but the characters that PCRE recog- + nizes as digits, spaces, or word characters remain the same set as before, all with values less than 256. This remains true even when PCRE - includes Unicode property support, because to do otherwise would slow - down PCRE in many common cases. If you really want to test for a wider - sense of, say, "digit", you must use Unicode property tests such as + includes Unicode property support, because to do otherwise would slow + down PCRE in many common cases. If you really want to test for a wider + sense of, say, "digit", you must use Unicode property tests such as \p{Nd}. - 8. Similarly, characters that match the POSIX named character classes + 8. Similarly, characters that match the POSIX named character classes are all low-valued characters. - 9. Case-insensitive matching applies only to characters whose values - are less than 128, unless PCRE is built with Unicode property support. - Even when Unicode property support is available, PCRE still uses its - own character tables when checking the case of low-valued characters, - so as not to degrade performance. The Unicode property information is + 9. Case-insensitive matching applies only to characters whose values + are less than 128, unless PCRE is built with Unicode property support. + Even when Unicode property support is available, PCRE still uses its + own character tables when checking the case of low-valued characters, + so as not to degrade performance. The Unicode property information is used only for characters with higher values. Even when Unicode property support is available, PCRE supports case-insensitive matching only when - there is a one-to-one mapping between a letter's cases. There are a - small number of many-to-one mappings in Unicode; these are not sup- + there is a one-to-one mapping between a letter's cases. There are a + small number of many-to-one mappings in Unicode; these are not sup- ported by PCRE. @@ -209,13 +212,13 @@ AUTHOR Philip Hazel University Computing Service, - Cambridge CB2 3QG, England. + Cambridge CB2 3QH, England. - Putting an actual email address here seems to have been a spam magnet, + Putting an actual email address here seems to have been a spam magnet, so I've taken it away. If you want to email me, use my initial and sur- name, separated by a dot, at the domain ucs.cam.ac.uk. -Last updated: 05 June 2006 +Last updated: 23 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -305,16 +308,21 @@ CODE VALUE OF NEWLINE --enable-newline-is-crlf - to the configure command. Whatever line ending convention is selected - when PCRE is built can be overridden when the library functions are - called. At build time it is conventional to use the standard for your - operating system. + to the configure command. There is a fourth option, specified by + + --enable-newline-is-any + + which causes PCRE to recognize any Unicode newline sequence. + + Whatever line ending convention is selected when PCRE is built can be + overridden when the library functions are called. At build time it is + conventional to use the standard for your operating system. BUILDING SHARED AND STATIC LIBRARIES - The PCRE building process uses libtool to build both shared and static - Unix libraries by default. You can suppress one of these by adding one + The PCRE building process uses libtool to build both shared and static + Unix libraries by default. You can suppress one of these by adding one of --disable-shared @@ -326,9 +334,9 @@ BUILDING SHARED AND STATIC LIBRARIES POSIX MALLOC USAGE When PCRE is called through the POSIX interface (see the pcreposix doc- - umentation), additional working storage is required for holding the - pointers to capturing substrings, because PCRE requires three integers - per substring, whereas the POSIX interface provides only two. If the + umentation), additional working storage is required for holding the + pointers to capturing substrings, because PCRE requires three integers + per substring, whereas the POSIX interface provides only two. If the number of expected substrings is small, the wrapper function uses space on the stack, because this is faster than using malloc() for each call. The default threshold above which the stack is no longer used is 10; it @@ -341,95 +349,100 @@ POSIX MALLOC USAGE HANDLING VERY LARGE PATTERNS - Within a compiled pattern, offset values are used to point from one - part to another (for example, from an opening parenthesis to an alter- - nation metacharacter). By default, two-byte values are used for these - offsets, leading to a maximum size for a compiled pattern of around - 64K. This is sufficient to handle all but the most gigantic patterns. - Nevertheless, some people do want to process enormous patterns, so it - is possible to compile PCRE to use three-byte or four-byte offsets by + Within a compiled pattern, offset values are used to point from one + part to another (for example, from an opening parenthesis to an alter- + nation metacharacter). By default, two-byte values are used for these + offsets, leading to a maximum size for a compiled pattern of around + 64K. This is sufficient to handle all but the most gigantic patterns. + Nevertheless, some people do want to process enormous patterns, so it + is possible to compile PCRE to use three-byte or four-byte offsets by adding a setting such as --with-link-size=3 - to the configure command. The value given must be 2, 3, or 4. Using - longer offsets slows down the operation of PCRE because it has to load + to the configure command. The value given must be 2, 3, or 4. Using + longer offsets slows down the operation of PCRE because it has to load additional bytes when handling them. - If you build PCRE with an increased link size, test 2 (and test 5 if - you are using UTF-8) will fail. Part of the output of these tests is a - representation of the compiled pattern, and this changes with the link + If you build PCRE with an increased link size, test 2 (and test 5 if + you are using UTF-8) will fail. Part of the output of these tests is a + representation of the compiled pattern, and this changes with the link size. AVOIDING EXCESSIVE STACK USAGE When matching with the pcre_exec() function, PCRE implements backtrack- - ing by making recursive calls to an internal function called match(). - In environments where the size of the stack is limited, this can se- - verely limit PCRE's operation. (The Unix environment does not usually + ing by making recursive calls to an internal function called match(). + In environments where the size of the stack is limited, this can se- + verely limit PCRE's operation. (The Unix environment does not usually suffer from this problem, but it may sometimes be necessary to increase - the maximum stack size. There is a discussion in the pcrestack docu- - mentation.) An alternative approach to recursion that uses memory from - the heap to remember data, instead of using recursive function calls, - has been implemented to work round the problem of limited stack size. + the maximum stack size. There is a discussion in the pcrestack docu- + mentation.) An alternative approach to recursion that uses memory from + the heap to remember data, instead of using recursive function calls, + has been implemented to work round the problem of limited stack size. If you want to build a version of PCRE that works this way, add --disable-stack-for-recursion - to the configure command. With this configuration, PCRE will use the - pcre_stack_malloc and pcre_stack_free variables to call memory manage- - ment functions. Separate functions are provided because the usage is - very predictable: the block sizes requested are always the same, and - the blocks are always freed in reverse order. A calling program might - be able to implement optimized functions that perform better than the - standard malloc() and free() functions. PCRE runs noticeably more + to the configure command. With this configuration, PCRE will use the + pcre_stack_malloc and pcre_stack_free variables to call memory manage- + ment functions. Separate functions are provided because the usage is + very predictable: the block sizes requested are always the same, and + the blocks are always freed in reverse order. A calling program might + be able to implement optimized functions that perform better than the + standard malloc() and free() functions. PCRE runs noticeably more slowly when built in this way. This option affects only the pcre_exec() function; it is not relevant for the the pcre_dfa_exec() function. LIMITING PCRE RESOURCE USAGE - Internally, PCRE has a function called match(), which it calls repeat- - edly (sometimes recursively) when matching a pattern with the - pcre_exec() function. By controlling the maximum number of times this - function may be called during a single matching operation, a limit can - be placed on the resources used by a single call to pcre_exec(). The - limit can be changed at run time, as described in the pcreapi documen- - tation. The default is 10 million, but this can be changed by adding a + Internally, PCRE has a function called match(), which it calls repeat- + edly (sometimes recursively) when matching a pattern with the + pcre_exec() function. By controlling the maximum number of times this + function may be called during a single matching operation, a limit can + be placed on the resources used by a single call to pcre_exec(). The + limit can be changed at run time, as described in the pcreapi documen- + tation. The default is 10 million, but this can be changed by adding a setting such as --with-match-limit=500000 - to the configure command. This setting has no effect on the + to the configure command. This setting has no effect on the pcre_dfa_exec() matching function. - In some environments it is desirable to limit the depth of recursive + In some environments it is desirable to limit the depth of recursive calls of match() more strictly than the total number of calls, in order - to restrict the maximum amount of stack (or heap, if --disable-stack- + to restrict the maximum amount of stack (or heap, if --disable-stack- for-recursion is specified) that is used. A second limit controls this; - it defaults to the value that is set for --with-match-limit, which - imposes no additional constraints. However, you can set a lower limit + it defaults to the value that is set for --with-match-limit, which + imposes no additional constraints. However, you can set a lower limit by adding, for example, --with-match-limit-recursion=10000 - to the configure command. This value can also be overridden at run + to the configure command. This value can also be overridden at run time. USING EBCDIC CODE - PCRE assumes by default that it will run in an environment where the - character code is ASCII (or Unicode, which is a superset of ASCII). - PCRE can, however, be compiled to run in an EBCDIC environment by + PCRE assumes by default that it will run in an environment where the + character code is ASCII (or Unicode, which is a superset of ASCII). + PCRE can, however, be compiled to run in an EBCDIC environment by adding --enable-ebcdic to the configure command. -Last updated: 06 June 2006 + +SEE ALSO + + pcreapi(3), pcre_config(3). + +Last updated: 30 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -466,7 +479,7 @@ PCRE MATCHING ALGORITHMS <something> <something else> <something further> there are three possible answers. The standard algorithm finds only one - of them, whereas the DFA algorithm finds all three. + of them, whereas the alternative algorithm finds all three. REGULAR EXPRESSIONS AS TREES @@ -507,21 +520,22 @@ THE STANDARD MATCHING ALGORITHM This provides support for capturing parentheses and back references. -THE DFA MATCHING ALGORITHM +THE ALTERNATIVE MATCHING ALGORITHM - DFA stands for "deterministic finite automaton", but you do not need to - understand the origins of that name. This algorithm conducts a breadth- - first search of the tree. Starting from the first matching point in the - subject, it scans the subject string from left to right, once, charac- - ter by character, and as it does this, it remembers all the paths - through the tree that represent valid matches. + This algorithm conducts a breadth-first search of the tree. Starting + from the first matching point in the subject, it scans the subject + string from left to right, once, character by character, and as it does + this, it remembers all the paths through the tree that represent valid + matches. In Friedl's terminology, this is a kind of "DFA algorithm", + though it is not implemented as a traditional finite state machine (it + keeps multiple states active simultaneously). - The scan continues until either the end of the subject is reached, or - there are no more unterminated paths. At this point, terminated paths - represent the different matching possibilities (if there are none, the - match has failed). Thus, if there is more than one possible match, + The scan continues until either the end of the subject is reached, or + there are no more unterminated paths. At this point, terminated paths + represent the different matching possibilities (if there are none, the + match has failed). Thus, if there is more than one possible match, this algorithm finds all of them, and in particular, it finds the long- - est. In PCRE, there is an option to stop the algorithm after the first + est. In PCRE, there is an option to stop the algorithm after the first match (which is necessarily the shortest) has been found. Note that all the matches that are found start at the same point in the @@ -529,75 +543,86 @@ THE DFA MATCHING ALGORITHM cat(er(pillar)?) - is matched against the string "the caterpillar catchment", the result - will be the three strings "cat", "cater", and "caterpillar" that start + is matched against the string "the caterpillar catchment", the result + will be the three strings "cat", "cater", and "caterpillar" that start at the fourth character of the subject. The algorithm does not automat- ically move on to find matches that start at later positions. There are a number of features of PCRE regular expressions that are not - supported by the DFA matching algorithm. They are as follows: + supported by the alternative matching algorithm. They are as follows: + + 1. Because the algorithm finds all possible matches, the greedy or + ungreedy nature of repetition quantifiers is not relevant. Greedy and + ungreedy quantifiers are treated in exactly the same way. However, pos- + sessive quantifiers can make a difference when what follows could also + match what is quantified, for example in a pattern like this: - 1. Because the algorithm finds all possible matches, the greedy or - ungreedy nature of repetition quantifiers is not relevant. Greedy and - ungreedy quantifiers are treated in exactly the same way. + ^a++\w! + + This pattern matches "aaab!" but not "aaa!", which would be matched by + a non-possessive quantifier. Similarly, if an atomic group is present, + it is matched as if it were a standalone pattern at the current point, + and the longest match is then "locked in" for the rest of the overall + pattern. 2. When dealing with multiple paths through the tree simultaneously, it - is not straightforward to keep track of captured substrings for the - different matching possibilities, and PCRE's implementation of this + is not straightforward to keep track of captured substrings for the + different matching possibilities, and PCRE's implementation of this algorithm does not attempt to do this. This means that no captured sub- strings are available. - 3. Because no substrings are captured, back references within the pat- + 3. Because no substrings are captured, back references within the pat- tern are not supported, and cause errors if encountered. - 4. For the same reason, conditional expressions that use a backrefer- - ence as the condition are not supported. + 4. For the same reason, conditional expressions that use a backrefer- + ence as the condition or test for a specific group recursion are not + supported. 5. Callouts are supported, but the value of the capture_top field is always 1, and the value of the capture_last field is always -1. 6. The \C escape sequence, which (in the standard algorithm) matches a - single byte, even in UTF-8 mode, is not supported because the DFA algo- - rithm moves through the subject string one character at a time, for all - active paths through the tree. + single byte, even in UTF-8 mode, is not supported because the alterna- + tive algorithm moves through the subject string one character at a + time, for all active paths through the tree. -ADVANTAGES OF THE DFA ALGORITHM +ADVANTAGES OF THE ALTERNATIVE ALGORITHM - Using the DFA matching algorithm provides the following advantages: + Using the alternative matching algorithm provides the following advan- + tages: 1. All possible matches (at a single point in the subject) are automat- - ically found, and in particular, the longest match is found. To find + ically found, and in particular, the longest match is found. To find more than one match using the standard algorithm, you have to do kludgy things with callouts. - 2. There is much better support for partial matching. The restrictions - on the content of the pattern that apply when using the standard algo- - rithm for partial matching do not apply to the DFA algorithm. For non- - anchored patterns, the starting position of a partial match is avail- - able. + 2. There is much better support for partial matching. The restrictions + on the content of the pattern that apply when using the standard algo- + rithm for partial matching do not apply to the alternative algorithm. + For non-anchored patterns, the starting position of a partial match is + available. - 3. Because the DFA algorithm scans the subject string just once, and - never needs to backtrack, it is possible to pass very long subject - strings to the matching function in several pieces, checking for par- - tial matching each time. + 3. Because the alternative algorithm scans the subject string just + once, and never needs to backtrack, it is possible to pass very long + subject strings to the matching function in several pieces, checking + for partial matching each time. -DISADVANTAGES OF THE DFA ALGORITHM +DISADVANTAGES OF THE ALTERNATIVE ALGORITHM - The DFA algorithm suffers from a number of disadvantages: + The alternative algorithm suffers from a number of disadvantages: - 1. It is substantially slower than the standard algorithm. This is - partly because it has to search for all possible matches, but is also + 1. It is substantially slower than the standard algorithm. This is + partly because it has to search for all possible matches, but is also because it is less susceptible to optimization. 2. Capturing parentheses and back references are not supported. - 3. The "atomic group" feature of PCRE regular expressions is supported, - but does not provide the advantage that it does for the standard algo- - rithm. + 3. Although atomic groups are supported, their use does not provide the + performance advantage that it does for the standard algorithm. -Last updated: 06 June 2006 +Last updated: 24 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -692,7 +717,7 @@ PCRE NATIVE API PCRE API OVERVIEW PCRE has its own native API, which is described in this document. There - is also a set of wrapper functions that correspond to the POSIX regular + are also some wrapper functions that correspond to the POSIX regular expression API. These are described in the pcreposix documentation. Both of these APIs define a set of C function calls. A C++ wrapper is distributed with PCRE. It is documented in the pcrecpp page. @@ -715,10 +740,10 @@ PCRE API OVERVIEW A second matching function, pcre_dfa_exec(), which is not Perl-compati- ble, is also provided. This uses a different algorithm for the match- ing. The alternative algorithm finds all possible matches (at a given - point in the subject). However, this algorithm does not return captured - substrings. A description of the two matching algorithms and their - advantages and disadvantages is given in the pcrematching documenta- - tion. + point in the subject), and scans the subject just once. However, this + algorithm does not return captured substrings. A description of the two + matching algorithms and their advantages and disadvantages is given in + the pcrematching documentation. In addition to the main compiling and matching functions, there are convenience functions for extracting captured substrings from a subject @@ -779,26 +804,38 @@ PCRE API OVERVIEW NEWLINES - PCRE supports three different conventions for indicating line breaks in - strings: a single CR character, a single LF character, or the two-char- - acter sequence CRLF. All three are used as "standard" by different - operating systems. When PCRE is built, a default can be specified. The - default default is LF, which is the Unix standard. When PCRE is run, - the default can be overridden, either when a pattern is compiled, or - when it is matched. + + PCRE supports four different conventions for indicating line breaks in + strings: a single CR (carriage return) character, a single LF (line- + feed) character, the two-character sequence CRLF, or any Unicode new- + line sequence. The Unicode newline sequences are the three just men- + tioned, plus the single characters VT (vertical tab, U+000B), FF (form- + feed, U+000C), NEL (next line, U+0085), LS (line separator, U+2028), + and PS (paragraph separator, U+2029). + + Each of the first three conventions is used by at least one operating + system as its standard newline sequence. When PCRE is built, a default + can be specified. The default default is LF, which is the Unix stan- + dard. When PCRE is run, the default can be overridden, either when a + pattern is compiled, or when it is matched. In the PCRE documentation the word "newline" is used to mean "the char- - acter or pair of characters that indicate a line break". + acter or pair of characters that indicate a line break". The choice of + newline convention affects the handling of the dot, circumflex, and + dollar metacharacters, the handling of #-comments in /x mode, and, when + CRLF is a recognized line ending sequence, the match position advance- + ment for a non-anchored pattern. The choice of newline convention does + not affect the interpretation of the \n or \r escape sequences. MULTITHREADING - The PCRE functions can be used in multi-threading applications, with + The PCRE functions can be used in multi-threading applications, with the proviso that the memory management functions pointed to by pcre_malloc, pcre_free, pcre_stack_malloc, and pcre_stack_free, and the callout function pointed to by pcre_callout, are shared by all threads. - The compiled form of a regular expression is not altered during match- + The compiled form of a regular expression is not altered during match- ing, so the same compiled pattern can safely be used by several threads at once. @@ -806,8 +843,8 @@ MULTITHREADING SAVING PRECOMPILED PATTERNS FOR LATER USE The compiled form of a regular expression can be saved and re-used at a - later time, possibly by a different program, and even on a host other - than the one on which it was compiled. Details are given in the + later time, possibly by a different program, and even on a host other + than the one on which it was compiled. Details are given in the pcreprecompile documentation. @@ -815,32 +852,33 @@ CHECKING BUILD-TIME OPTIONS int pcre_config(int what, void *where); - The function pcre_config() makes it possible for a PCRE client to dis- + The function pcre_config() makes it possible for a PCRE client to dis- cover which optional features have been compiled into the PCRE library. - The pcrebuild documentation has more details about these optional fea- + The pcrebuild documentation has more details about these optional fea- tures. - The first argument for pcre_config() is an integer, specifying which + The first argument for pcre_config() is an integer, specifying which information is required; the second argument is a pointer to a variable - into which the information is placed. The following information is + into which the information is placed. The following information is available: PCRE_CONFIG_UTF8 - The output is an integer that is set to one if UTF-8 support is avail- + The output is an integer that is set to one if UTF-8 support is avail- able; otherwise it is set to zero. PCRE_CONFIG_UNICODE_PROPERTIES - The output is an integer that is set to one if support for Unicode + The output is an integer that is set to one if support for Unicode character properties is available; otherwise it is set to zero. PCRE_CONFIG_NEWLINE - The output is an integer whose value specifies the default character - sequence that is recognized as meaning "newline". The three values that - are supported are: 10 for LF, 13 for CR, and 3338 for CRLF. The default - should normally be the standard sequence for your operating system. + The output is an integer whose value specifies the default character + sequence that is recognized as meaning "newline". The four values that + are supported are: 10 for LF, 13 for CR, 3338 for CRLF, and -1 for ANY. + The default should normally be the standard sequence for your operating + system. PCRE_CONFIG_LINK_SIZE @@ -909,8 +947,8 @@ COMPILING A PATTERN fully relocatable, because it may contain a copy of the tableptr argu- ment, which is an address (see below). - The options argument contains independent bits that affect the compila- - tion. It should be zero if no options are required. The available + The options argument contains various bit settings that affect the com- + pilation. It should be zero if no options are required. The available options are described below. Some of them, in particular, those that are compatible with Perl, can also be set and unset from within the pattern (see the detailed description in the pcrepattern documenta- @@ -1000,7 +1038,7 @@ COMPILING A PATTERN not match when the current position is at a newline. This option is equivalent to Perl's /s option, and it can be changed within a pattern by a (?s) option setting. A negative class such as [^a] always matches - newlines, independent of the setting of this option. + newline characters, independent of the setting of this option. PCRE_DUPNAMES @@ -1064,19 +1102,37 @@ COMPILING A PATTERN PCRE_NEWLINE_CR PCRE_NEWLINE_LF PCRE_NEWLINE_CRLF + PCRE_NEWLINE_ANY These options override the default newline definition that was chosen when PCRE was built. Setting the first or the second specifies that a newline is indicated by a single character (CR or LF, respectively). - Setting both of them specifies that a newline is indicated by the two- - character CRLF sequence. For convenience, PCRE_NEWLINE_CRLF is defined - to contain both bits. The only time that a line break is relevant when - compiling a pattern is if PCRE_EXTENDED is set, and an unescaped # out- - side a character class is encountered. This indicates a comment that - lasts until after the next newline. - - The newline option set at compile time becomes the default that is used - for pcre_exec() and pcre_dfa_exec(), but it can be overridden. + Setting PCRE_NEWLINE_CRLF specifies that a newline is indicated by the + two-character CRLF sequence. Setting PCRE_NEWLINE_ANY specifies that + any Unicode newline sequence should be recognized. The Unicode newline + sequences are the three just mentioned, plus the single characters VT + (vertical tab, U+000B), FF (formfeed, U+000C), NEL (next line, U+0085), + LS (line separator, U+2028), and PS (paragraph separator, U+2029). The + last two are recognized only in UTF-8 mode. + + The newline setting in the options word uses three bits that are + treated as a number, giving eight possibilities. Currently only five + are used (default plus the four values above). This means that if you + set more than one newline option, the combination may or may not be + sensible. For example, PCRE_NEWLINE_CR with PCRE_NEWLINE_LF is equiva- + lent to PCRE_NEWLINE_CRLF, but other combinations yield unused numbers + and cause an error. + + The only time that a line break is specially recognized when compiling + a pattern is if PCRE_EXTENDED is set, and an unescaped # outside a + character class is encountered. This indicates a comment that lasts + until after the next line break sequence. In other circumstances, line + break sequences are treated as literal data, except that in + PCRE_EXTENDED mode, both CR and LF are treated as whitespace characters + and are therefore ignored. + + The newline option that is set at compile time becomes the default that + is used for pcre_exec() and pcre_dfa_exec(), but it can be overridden. PCRE_NO_AUTO_CAPTURE @@ -1119,7 +1175,8 @@ COMPILATION ERROR CODES The following table lists the error codes than may be returned by pcre_compile2(), along with the error messages that may be returned by - both compiling functions. + both compiling functions. As PCRE has developed, some error codes have + fallen out of use. To avoid confusion, they have not been re-used. 0 no error 1 \ at end of pattern @@ -1131,7 +1188,7 @@ COMPILATION ERROR CODES 7 invalid escape sequence in character class 8 range out of order in character class 9 nothing to repeat - 10 operand of unlimited repeat could match the empty string + 10 [this code is not in use] 11 internal error: unexpected repeat 12 unrecognized character after (? 13 POSIX named classes are supported only within a class @@ -1140,7 +1197,7 @@ COMPILATION ERROR CODES 16 erroffset passed as NULL 17 unknown option bit(s) set 18 missing ) after comment - 19 parentheses nested too deeply + 19 [this code is not in use] 20 regular expression too large 21 failed to get memory 22 unmatched parentheses @@ -1154,7 +1211,7 @@ COMPILATION ERROR CODES 30 unknown POSIX class name 31 POSIX collating elements are not supported 32 this version of PCRE is not compiled with PCRE_UTF8 support - 33 spare error + 33 [this code is not in use] 34 character value in \x{...} sequence is too large 35 invalid condition (?(0) 36 \C not allowed in lookbehind assertion @@ -1163,7 +1220,7 @@ COMPILATION ERROR CODES 39 closing ) for (?C expected 40 recursive call could loop indefinitely 41 unrecognized character after (?P - 42 syntax error after (?P + 42 syntax error in subpattern name (missing terminator) 43 two named subpatterns have the same name 44 invalid UTF-8 string 45 support for \P, \p, and \X has not been compiled @@ -1173,6 +1230,12 @@ COMPILATION ERROR CODES 49 too many named subpatterns (maximum 10,000) 50 repeated subpattern is too long 51 octal value is greater than \377 (not in UTF-8 mode) + 52 internal error: overran compiling workspace + 53 internal error: previously-checked referenced subpattern not + found + 54 DEFINE group contains more than one branch + 55 repeating a DEFINE group is not allowed + 56 inconsistent NEWLINE options" STUDYING A PATTERN @@ -1331,7 +1394,7 @@ INFORMATION ABOUT A PATTERN is still recognized for backwards compatibility.) If there is a fixed first byte, for example, from a pattern such as - (cat|cow|coyote). Otherwise, if either + (cat|cow|coyote), its value is returned. Otherwise, if either (a) the pattern was compiled with the PCRE_MULTILINE option, and every branch starts with "^", or @@ -1388,8 +1451,8 @@ INFORMATION ABOUT A PATTERN PCRE_EXTENDED is set, so white space - including newlines - is ignored): - (?P<date> (?P<year>(\d\d)?\d\d) - - (?P<month>\d\d) - (?P<day>\d\d) ) + (?<date> (?<year>(\d\d)?\d\d) - + (?<month>\d\d) - (?<day>\d\d) ) There are four named subpatterns, so the table has four entries, and each entry in the table is eight bytes long. The table is as follows, @@ -1616,191 +1679,197 @@ MATCHING A PATTERN: THE TRADITIONAL FUNCTION PCRE_NEWLINE_CR PCRE_NEWLINE_LF PCRE_NEWLINE_CRLF + PCRE_NEWLINE_ANY These options override the newline definition that was chosen or defaulted when the pattern was compiled. For details, see the descrip- - tion pcre_compile() above. During matching, the newline choice affects - the behaviour of the dot, circumflex, and dollar metacharacters. + tion of pcre_compile() above. During matching, the newline choice + affects the behaviour of the dot, circumflex, and dollar metacharac- + ters. It may also alter the way the match position is advanced after a + match failure for an unanchored pattern. When PCRE_NEWLINE_CRLF or + PCRE_NEWLINE_ANY is set, and a match attempt fails when the current + position is at a CRLF sequence, the match position is advanced by two + characters instead of one, in other words, to after the CRLF. PCRE_NOTBOL This option specifies that first character of the subject string is not - the beginning of a line, so the circumflex metacharacter should not - match before it. Setting this without PCRE_MULTILINE (at compile time) - causes circumflex never to match. This option affects only the behav- + the beginning of a line, so the circumflex metacharacter should not + match before it. Setting this without PCRE_MULTILINE (at compile time) + causes circumflex never to match. This option affects only the behav- iour of the circumflex metacharacter. It does not affect \A. PCRE_NOTEOL This option specifies that the end of the subject string is not the end - of a line, so the dollar metacharacter should not match it nor (except - in multiline mode) a newline immediately before it. Setting this with- + of a line, so the dollar metacharacter should not match it nor (except + in multiline mode) a newline immediately before it. Setting this with- out PCRE_MULTILINE (at compile time) causes dollar never to match. This - option affects only the behaviour of the dollar metacharacter. It does + option affects only the behaviour of the dollar metacharacter. It does not affect \Z or \z. PCRE_NOTEMPTY An empty string is not considered to be a valid match if this option is - set. If there are alternatives in the pattern, they are tried. If all - the alternatives match the empty string, the entire match fails. For + set. If there are alternatives in the pattern, they are tried. If all + the alternatives match the empty string, the entire match fails. For example, if the pattern a?b? - is applied to a string not beginning with "a" or "b", it matches the - empty string at the start of the subject. With PCRE_NOTEMPTY set, this + is applied to a string not beginning with "a" or "b", it matches the + empty string at the start of the subject. With PCRE_NOTEMPTY set, this match is not valid, so PCRE searches further into the string for occur- rences of "a" or "b". Perl has no direct equivalent of PCRE_NOTEMPTY, but it does make a spe- - cial case of a pattern match of the empty string within its split() - function, and when using the /g modifier. It is possible to emulate + cial case of a pattern match of the empty string within its split() + function, and when using the /g modifier. It is possible to emulate Perl's behaviour after matching a null string by first trying the match again at the same offset with PCRE_NOTEMPTY and PCRE_ANCHORED, and then - if that fails by advancing the starting offset (see below) and trying + if that fails by advancing the starting offset (see below) and trying an ordinary match again. There is some code that demonstrates how to do this in the pcredemo.c sample program. PCRE_NO_UTF8_CHECK When PCRE_UTF8 is set at compile time, the validity of the subject as a - UTF-8 string is automatically checked when pcre_exec() is subsequently - called. The value of startoffset is also checked to ensure that it - points to the start of a UTF-8 character. If an invalid UTF-8 sequence + UTF-8 string is automatically checked when pcre_exec() is subsequently + called. The value of startoffset is also checked to ensure that it + points to the start of a UTF-8 character. If an invalid UTF-8 sequence of bytes is found, pcre_exec() returns the error PCRE_ERROR_BADUTF8. If - startoffset contains an invalid value, PCRE_ERROR_BADUTF8_OFFSET is + startoffset contains an invalid value, PCRE_ERROR_BADUTF8_OFFSET is returned. - If you already know that your subject is valid, and you want to skip - these checks for performance reasons, you can set the - PCRE_NO_UTF8_CHECK option when calling pcre_exec(). You might want to - do this for the second and subsequent calls to pcre_exec() if you are - making repeated calls to find all the matches in a single subject - string. However, you should be sure that the value of startoffset - points to the start of a UTF-8 character. When PCRE_NO_UTF8_CHECK is - set, the effect of passing an invalid UTF-8 string as a subject, or a - value of startoffset that does not point to the start of a UTF-8 char- + If you already know that your subject is valid, and you want to skip + these checks for performance reasons, you can set the + PCRE_NO_UTF8_CHECK option when calling pcre_exec(). You might want to + do this for the second and subsequent calls to pcre_exec() if you are + making repeated calls to find all the matches in a single subject + string. However, you should be sure that the value of startoffset + points to the start of a UTF-8 character. When PCRE_NO_UTF8_CHECK is + set, the effect of passing an invalid UTF-8 string as a subject, or a + value of startoffset that does not point to the start of a UTF-8 char- acter, is undefined. Your program may crash. PCRE_PARTIAL - This option turns on the partial matching feature. If the subject - string fails to match the pattern, but at some point during the match- - ing process the end of the subject was reached (that is, the subject - partially matches the pattern and the failure to match occurred only - because there were not enough subject characters), pcre_exec() returns - PCRE_ERROR_PARTIAL instead of PCRE_ERROR_NOMATCH. When PCRE_PARTIAL is - used, there are restrictions on what may appear in the pattern. These + This option turns on the partial matching feature. If the subject + string fails to match the pattern, but at some point during the match- + ing process the end of the subject was reached (that is, the subject + partially matches the pattern and the failure to match occurred only + because there were not enough subject characters), pcre_exec() returns + PCRE_ERROR_PARTIAL instead of PCRE_ERROR_NOMATCH. When PCRE_PARTIAL is + used, there are restrictions on what may appear in the pattern. These are discussed in the pcrepartial documentation. The string to be matched by pcre_exec() - The subject string is passed to pcre_exec() as a pointer in subject, a - length in length, and a starting byte offset in startoffset. In UTF-8 - mode, the byte offset must point to the start of a UTF-8 character. - Unlike the pattern string, the subject may contain binary zero bytes. - When the starting offset is zero, the search for a match starts at the + The subject string is passed to pcre_exec() as a pointer in subject, a + length in length, and a starting byte offset in startoffset. In UTF-8 + mode, the byte offset must point to the start of a UTF-8 character. + Unlike the pattern string, the subject may contain binary zero bytes. + When the starting offset is zero, the search for a match starts at the beginning of the subject, and this is by far the most common case. - A non-zero starting offset is useful when searching for another match - in the same subject by calling pcre_exec() again after a previous suc- - cess. Setting startoffset differs from just passing over a shortened - string and setting PCRE_NOTBOL in the case of a pattern that begins + A non-zero starting offset is useful when searching for another match + in the same subject by calling pcre_exec() again after a previous suc- + cess. Setting startoffset differs from just passing over a shortened + string and setting PCRE_NOTBOL in the case of a pattern that begins with any kind of lookbehind. For example, consider the pattern \Biss\B - which finds occurrences of "iss" in the middle of words. (\B matches - only if the current position in the subject is not a word boundary.) - When applied to the string "Mississipi" the first call to pcre_exec() - finds the first occurrence. If pcre_exec() is called again with just - the remainder of the subject, namely "issipi", it does not match, + which finds occurrences of "iss" in the middle of words. (\B matches + only if the current position in the subject is not a word boundary.) + When applied to the string "Mississipi" the first call to pcre_exec() + finds the first occurrence. If pcre_exec() is called again with just + the remainder of the subject, namely "issipi", it does not match, because \B is always false at the start of the subject, which is deemed - to be a word boundary. However, if pcre_exec() is passed the entire + to be a word boundary. However, if pcre_exec() is passed the entire string again, but with startoffset set to 4, it finds the second occur- - rence of "iss" because it is able to look behind the starting point to + rence of "iss" because it is able to look behind the starting point to discover that it is preceded by a letter. - If a non-zero starting offset is passed when the pattern is anchored, + If a non-zero starting offset is passed when the pattern is anchored, one attempt to match at the given offset is made. This can only succeed - if the pattern does not require the match to be at the start of the + if the pattern does not require the match to be at the start of the subject. How pcre_exec() returns captured substrings - In general, a pattern matches a certain portion of the subject, and in - addition, further substrings from the subject may be picked out by - parts of the pattern. Following the usage in Jeffrey Friedl's book, - this is called "capturing" in what follows, and the phrase "capturing - subpattern" is used for a fragment of a pattern that picks out a sub- - string. PCRE supports several other kinds of parenthesized subpattern + In general, a pattern matches a certain portion of the subject, and in + addition, further substrings from the subject may be picked out by + parts of the pattern. Following the usage in Jeffrey Friedl's book, + this is called "capturing" in what follows, and the phrase "capturing + subpattern" is used for a fragment of a pattern that picks out a sub- + string. PCRE supports several other kinds of parenthesized subpattern that do not cause substrings to be captured. - Captured substrings are returned to the caller via a vector of integer - offsets whose address is passed in ovector. The number of elements in - the vector is passed in ovecsize, which must be a non-negative number. + Captured substrings are returned to the caller via a vector of integer + offsets whose address is passed in ovector. The number of elements in + the vector is passed in ovecsize, which must be a non-negative number. Note: this argument is NOT the size of ovector in bytes. - The first two-thirds of the vector is used to pass back captured sub- - strings, each substring using a pair of integers. The remaining third - of the vector is used as workspace by pcre_exec() while matching cap- - turing subpatterns, and is not available for passing back information. - The length passed in ovecsize should always be a multiple of three. If + The first two-thirds of the vector is used to pass back captured sub- + strings, each substring using a pair of integers. The remaining third + of the vector is used as workspace by pcre_exec() while matching cap- + turing subpatterns, and is not available for passing back information. + The length passed in ovecsize should always be a multiple of three. If it is not, it is rounded down. - When a match is successful, information about captured substrings is - returned in pairs of integers, starting at the beginning of ovector, - and continuing up to two-thirds of its length at the most. The first + When a match is successful, information about captured substrings is + returned in pairs of integers, starting at the beginning of ovector, + and continuing up to two-thirds of its length at the most. The first element of a pair is set to the offset of the first character in a sub- - string, and the second is set to the offset of the first character - after the end of a substring. The first pair, ovector[0] and ovec- - tor[1], identify the portion of the subject string matched by the - entire pattern. The next pair is used for the first capturing subpat- + string, and the second is set to the offset of the first character + after the end of a substring. The first pair, ovector[0] and ovec- + tor[1], identify the portion of the subject string matched by the + entire pattern. The next pair is used for the first capturing subpat- tern, and so on. The value returned by pcre_exec() is one more than the highest numbered pair that has been set. For example, if two substrings - have been captured, the returned value is 3. If there are no capturing - subpatterns, the return value from a successful match is 1, indicating + have been captured, the returned value is 3. If there are no capturing + subpatterns, the return value from a successful match is 1, indicating that just the first pair of offsets has been set. If a capturing subpattern is matched repeatedly, it is the last portion of the string that it matched that is returned. - If the vector is too small to hold all the captured substring offsets, + If the vector is too small to hold all the captured substring offsets, it is used as far as possible (up to two-thirds of its length), and the - function returns a value of zero. In particular, if the substring off- + function returns a value of zero. In particular, if the substring off- sets are not of interest, pcre_exec() may be called with ovector passed - as NULL and ovecsize as zero. However, if the pattern contains back - references and the ovector is not big enough to remember the related - substrings, PCRE has to get additional memory for use during matching. + as NULL and ovecsize as zero. However, if the pattern contains back + references and the ovector is not big enough to remember the related + substrings, PCRE has to get additional memory for use during matching. Thus it is usually advisable to supply an ovector. - The pcre_info() function can be used to find out how many capturing - subpatterns there are in a compiled pattern. The smallest size for - ovector that will allow for n captured substrings, in addition to the + The pcre_info() function can be used to find out how many capturing + subpatterns there are in a compiled pattern. The smallest size for + ovector that will allow for n captured substrings, in addition to the offsets of the substring matched by the whole pattern, is (n+1)*3. - It is possible for capturing subpattern number n+1 to match some part + It is possible for capturing subpattern number n+1 to match some part of the subject when subpattern n has not been used at all. For example, - if the string "abc" is matched against the pattern (a|(z))(bc) the + if the string "abc" is matched against the pattern (a|(z))(bc) the return from the function is 4, and subpatterns 1 and 3 are matched, but - 2 is not. When this happens, both values in the offset pairs corre- + 2 is not. When this happens, both values in the offset pairs corre- sponding to unused subpatterns are set to -1. - Offset values that correspond to unused subpatterns at the end of the - expression are also set to -1. For example, if the string "abc" is - matched against the pattern (abc)(x(yz)?)? subpatterns 2 and 3 are not - matched. The return from the function is 2, because the highest used + Offset values that correspond to unused subpatterns at the end of the + expression are also set to -1. For example, if the string "abc" is + matched against the pattern (abc)(x(yz)?)? subpatterns 2 and 3 are not + matched. The return from the function is 2, because the highest used capturing subpattern number is 1. However, you can refer to the offsets - for the second and third capturing subpatterns if you wish (assuming + for the second and third capturing subpatterns if you wish (assuming the vector is large enough, of course). - Some convenience functions are provided for extracting the captured + Some convenience functions are provided for extracting the captured substrings as separate strings. These are described below. Error return values from pcre_exec() - If pcre_exec() fails, it returns a negative number. The following are + If pcre_exec() fails, it returns a negative number. The following are defined in the header file: PCRE_ERROR_NOMATCH (-1) @@ -1809,7 +1878,7 @@ MATCHING A PATTERN: THE TRADITIONAL FUNCTION PCRE_ERROR_NULL (-2) - Either code or subject was passed as NULL, or ovector was NULL and + Either code or subject was passed as NULL, or ovector was NULL and ovecsize was not zero. PCRE_ERROR_BADOPTION (-3) @@ -1818,80 +1887,94 @@ MATCHING A PATTERN: THE TRADITIONAL FUNCTION PCRE_ERROR_BADMAGIC (-4) - PCRE stores a 4-byte "magic number" at the start of the compiled code, + PCRE stores a 4-byte "magic number" at the start of the compiled code, to catch the case when it is passed a junk pointer and to detect when a pattern that was compiled in an environment of one endianness is run in - an environment with the other endianness. This is the error that PCRE + an environment with the other endianness. This is the error that PCRE gives when the magic number is not present. - PCRE_ERROR_UNKNOWN_NODE (-5) + PCRE_ERROR_UNKNOWN_OPCODE (-5) While running the pattern match, an unknown item was encountered in the - compiled pattern. This error could be caused by a bug in PCRE or by + compiled pattern. This error could be caused by a bug in PCRE or by overwriting of the compiled pattern. PCRE_ERROR_NOMEMORY (-6) - If a pattern contains back references, but the ovector that is passed + If a pattern contains back references, but the ovector that is passed to pcre_exec() is not big enough to remember the referenced substrings, - PCRE gets a block of memory at the start of matching to use for this - purpose. If the call via pcre_malloc() fails, this error is given. The + PCRE gets a block of memory at the start of matching to use for this + purpose. If the call via pcre_malloc() fails, this error is given. The memory is automatically freed at the end of matching. PCRE_ERROR_NOSUBSTRING (-7) - This error is used by the pcre_copy_substring(), pcre_get_substring(), + This error is used by the pcre_copy_substring(), pcre_get_substring(), and pcre_get_substring_list() functions (see below). It is never returned by pcre_exec(). PCRE_ERROR_MATCHLIMIT (-8) - The backtracking limit, as specified by the match_limit field in a - pcre_extra structure (or defaulted) was reached. See the description + The backtracking limit, as specified by the match_limit field in a + pcre_extra structure (or defaulted) was reached. See the description above. - PCRE_ERROR_RECURSIONLIMIT (-21) - - The internal recursion limit, as specified by the match_limit_recursion - field in a pcre_extra structure (or defaulted) was reached. See the - description above. - PCRE_ERROR_CALLOUT (-9) This error is never generated by pcre_exec() itself. It is provided for - use by callout functions that want to yield a distinctive error code. + use by callout functions that want to yield a distinctive error code. See the pcrecallout documentation for details. PCRE_ERROR_BADUTF8 (-10) - A string that contains an invalid UTF-8 byte sequence was passed as a + A string that contains an invalid UTF-8 byte sequence was passed as a subject. PCRE_ERROR_BADUTF8_OFFSET (-11) The UTF-8 byte sequence that was passed as a subject was valid, but the - value of startoffset did not point to the beginning of a UTF-8 charac- + value of startoffset did not point to the beginning of a UTF-8 charac- ter. PCRE_ERROR_PARTIAL (-12) - The subject string did not match, but it did match partially. See the + The subject string did not match, but it did match partially. See the pcrepartial documentation for details of partial matching. PCRE_ERROR_BADPARTIAL (-13) - The PCRE_PARTIAL option was used with a compiled pattern containing - items that are not supported for partial matching. See the pcrepartial + The PCRE_PARTIAL option was used with a compiled pattern containing + items that are not supported for partial matching. See the pcrepartial documentation for details of partial matching. PCRE_ERROR_INTERNAL (-14) - An unexpected internal error has occurred. This error could be caused + An unexpected internal error has occurred. This error could be caused by a bug in PCRE or by overwriting of the compiled pattern. PCRE_ERROR_BADCOUNT (-15) - This error is given if the value of the ovecsize argument is negative. + This error is given if the value of the ovecsize argument is negative. + + PCRE_ERROR_RECURSIONLIMIT (-21) + + The internal recursion limit, as specified by the match_limit_recursion + field in a pcre_extra structure (or defaulted) was reached. See the + description above. + + PCRE_ERROR_NULLWSLIMIT (-22) + + When a group that can match an empty substring is repeated with an + unbounded upper limit, the subject position at the start of the group + must be remembered, so that a test for an empty string can be made when + the end of the group is reached. Some workspace is required for this; + if it runs out, this error is given. + + PCRE_ERROR_BADNEWLINE (-23) + + An invalid combination of PCRE_NEWLINE_xxx options was given. + + Error numbers -16 to -20 are not used by pcre_exec(). EXTRACTING CAPTURED SUBSTRINGS BY NUMBER @@ -1907,57 +1990,58 @@ EXTRACTING CAPTURED SUBSTRINGS BY NUMBER int pcre_get_substring_list(const char *subject, int *ovector, int stringcount, const char ***listptr); - Captured substrings can be accessed directly by using the offsets - returned by pcre_exec() in ovector. For convenience, the functions + Captured substrings can be accessed directly by using the offsets + returned by pcre_exec() in ovector. For convenience, the functions pcre_copy_substring(), pcre_get_substring(), and pcre_get_sub- - string_list() are provided for extracting captured substrings as new, - separate, zero-terminated strings. These functions identify substrings - by number. The next section describes functions for extracting named + string_list() are provided for extracting captured substrings as new, + separate, zero-terminated strings. These functions identify substrings + by number. The next section describes functions for extracting named substrings. - A substring that contains a binary zero is correctly extracted and has - a further zero added on the end, but the result is not, of course, a C - string. However, you can process such a string by referring to the - length that is returned by pcre_copy_substring() and pcre_get_sub- + A substring that contains a binary zero is correctly extracted and has + a further zero added on the end, but the result is not, of course, a C + string. However, you can process such a string by referring to the + length that is returned by pcre_copy_substring() and pcre_get_sub- string(). Unfortunately, the interface to pcre_get_substring_list() is - not adequate for handling strings containing binary zeros, because the + not adequate for handling strings containing binary zeros, because the end of the final string is not independently indicated. - The first three arguments are the same for all three of these func- - tions: subject is the subject string that has just been successfully + The first three arguments are the same for all three of these func- + tions: subject is the subject string that has just been successfully matched, ovector is a pointer to the vector of integer offsets that was passed to pcre_exec(), and stringcount is the number of substrings that - were captured by the match, including the substring that matched the + were captured by the match, including the substring that matched the entire regular expression. This is the value returned by pcre_exec() if - it is greater than zero. If pcre_exec() returned zero, indicating that - it ran out of space in ovector, the value passed as stringcount should + it is greater than zero. If pcre_exec() returned zero, indicating that + it ran out of space in ovector, the value passed as stringcount should be the number of elements in the vector divided by three. - The functions pcre_copy_substring() and pcre_get_substring() extract a - single substring, whose number is given as stringnumber. A value of - zero extracts the substring that matched the entire pattern, whereas - higher values extract the captured substrings. For pcre_copy_sub- - string(), the string is placed in buffer, whose length is given by - buffersize, while for pcre_get_substring() a new block of memory is - obtained via pcre_malloc, and its address is returned via stringptr. - The yield of the function is the length of the string, not including - the terminating zero, or one of + The functions pcre_copy_substring() and pcre_get_substring() extract a + single substring, whose number is given as stringnumber. A value of + zero extracts the substring that matched the entire pattern, whereas + higher values extract the captured substrings. For pcre_copy_sub- + string(), the string is placed in buffer, whose length is given by + buffersize, while for pcre_get_substring() a new block of memory is + obtained via pcre_malloc, and its address is returned via stringptr. + The yield of the function is the length of the string, not including + the terminating zero, or one of these error codes: PCRE_ERROR_NOMEMORY (-6) - The buffer was too small for pcre_copy_substring(), or the attempt to + The buffer was too small for pcre_copy_substring(), or the attempt to get memory failed for pcre_get_substring(). PCRE_ERROR_NOSUBSTRING (-7) There is no substring whose number is stringnumber. - The pcre_get_substring_list() function extracts all available sub- - strings and builds a list of pointers to them. All this is done in a + The pcre_get_substring_list() function extracts all available sub- + strings and builds a list of pointers to them. All this is done in a single block of memory that is obtained via pcre_malloc. The address of - the memory block is returned via listptr, which is also the start of - the list of string pointers. The end of the list is marked by a NULL - pointer. The yield of the function is zero if all went well, or + the memory block is returned via listptr, which is also the start of + the list of string pointers. The end of the list is marked by a NULL + pointer. The yield of the function is zero if all went well, or the + error code PCRE_ERROR_NOMEMORY (-6) @@ -1999,7 +2083,7 @@ EXTRACTING CAPTURED SUBSTRINGS BY NAME To extract a substring by name, you first have to find associated num- ber. For example, for this pattern - (a+)b(?P<xxx>\d+)... + (a+)b(?<xxx>\d+)... the number of the subpattern called "xxx" is 2. If the name is known to be unique (PCRE_DUPNAMES was not set), you can find the number from the @@ -2050,11 +2134,11 @@ DUPLICATE SUBPATTERN NAMES third and fourth are pointers to variables which are updated by the function. After it has run, they point to the first and last entries in the name-to-number table for the given name. The function itself - returns the length of each entry, or PCRE_ERROR_NOSUBSTRING if there - are none. The format of the table is described above in the section - entitled Information about a pattern. Given all the relevant entries - for the name, you can extract each of their numbers, and hence the cap- - tured data, if any. + returns the length of each entry, or PCRE_ERROR_NOSUBSTRING (-7) if + there are none. The format of the table is described above in the sec- + tion entitled Information about a pattern. Given all the relevant + entries for the name, you can extract each of their numbers, and hence + the captured data, if any. FINDING ALL POSSIBLE MATCHES @@ -2083,23 +2167,24 @@ MATCHING A PATTERN: THE ALTERNATIVE FUNCTION int *workspace, int wscount); The function pcre_dfa_exec() is called to match a subject string - against a compiled pattern, using a "DFA" matching algorithm. This has - different characteristics to the normal algorithm, and is not compati- - ble with Perl. Some of the features of PCRE patterns are not supported. - Nevertheless, there are times when this kind of matching can be useful. - For a discussion of the two matching algorithms, see the pcrematching - documentation. + against a compiled pattern, using a matching algorithm that scans the + subject string just once, and does not backtrack. This has different + characteristics to the normal algorithm, and is not compatible with + Perl. Some of the features of PCRE patterns are not supported. Never- + theless, there are times when this kind of matching can be useful. For + a discussion of the two matching algorithms, see the pcrematching docu- + mentation. - The arguments for the pcre_dfa_exec() function are the same as for + The arguments for the pcre_dfa_exec() function are the same as for pcre_exec(), plus two extras. The ovector argument is used in a differ- - ent way, and this is described below. The other common arguments are - used in the same way as for pcre_exec(), so their description is not + ent way, and this is described below. The other common arguments are + used in the same way as for pcre_exec(), so their description is not repeated here. - The two additional arguments provide workspace for the function. The - workspace vector should contain at least 20 elements. It is used for + The two additional arguments provide workspace for the function. The + workspace vector should contain at least 20 elements. It is used for keeping track of multiple paths through the pattern tree. More - workspace will be needed for patterns and subjects where there are a + workspace will be needed for patterns and subjects where there are a lot of potential matches. Here is an example of a simple call to pcre_dfa_exec(): @@ -2121,47 +2206,47 @@ MATCHING A PATTERN: THE ALTERNATIVE FUNCTION Option bits for pcre_dfa_exec() - The unused bits of the options argument for pcre_dfa_exec() must be - zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NEW- - LINE_xxx, PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, PCRE_NO_UTF8_CHECK, + The unused bits of the options argument for pcre_dfa_exec() must be + zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NEW- + LINE_xxx, PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, PCRE_NO_UTF8_CHECK, PCRE_PARTIAL, PCRE_DFA_SHORTEST, and PCRE_DFA_RESTART. All but the last three of these are the same as for pcre_exec(), so their description is not repeated here. PCRE_PARTIAL - This has the same general effect as it does for pcre_exec(), but the - details are slightly different. When PCRE_PARTIAL is set for - pcre_dfa_exec(), the return code PCRE_ERROR_NOMATCH is converted into - PCRE_ERROR_PARTIAL if the end of the subject is reached, there have + This has the same general effect as it does for pcre_exec(), but the + details are slightly different. When PCRE_PARTIAL is set for + pcre_dfa_exec(), the return code PCRE_ERROR_NOMATCH is converted into + PCRE_ERROR_PARTIAL if the end of the subject is reached, there have been no complete matches, but there is still at least one matching pos- - sibility. The portion of the string that provided the partial match is + sibility. The portion of the string that provided the partial match is set as the first matching string. PCRE_DFA_SHORTEST - Setting the PCRE_DFA_SHORTEST option causes the matching algorithm to - stop as soon as it has found one match. Because of the way the DFA - algorithm works, this is necessarily the shortest possible match at the - first possible matching point in the subject string. + Setting the PCRE_DFA_SHORTEST option causes the matching algorithm to + stop as soon as it has found one match. Because of the way the alterna- + tive algorithm works, this is necessarily the shortest possible match + at the first possible matching point in the subject string. PCRE_DFA_RESTART - When pcre_dfa_exec() is called with the PCRE_PARTIAL option, and - returns a partial match, it is possible to call it again, with addi- - tional subject characters, and have it continue with the same match. - The PCRE_DFA_RESTART option requests this action; when it is set, the - workspace and wscount options must reference the same vector as before - because data about the match so far is left in them after a partial - match. There is more discussion of this facility in the pcrepartial + When pcre_dfa_exec() is called with the PCRE_PARTIAL option, and + returns a partial match, it is possible to call it again, with addi- + tional subject characters, and have it continue with the same match. + The PCRE_DFA_RESTART option requests this action; when it is set, the + workspace and wscount options must reference the same vector as before + because data about the match so far is left in them after a partial + match. There is more discussion of this facility in the pcrepartial documentation. Successful returns from pcre_dfa_exec() - When pcre_dfa_exec() succeeds, it may have matched more than one sub- + When pcre_dfa_exec() succeeds, it may have matched more than one sub- string in the subject. Note, however, that all the matches from one run - of the function start at the same point in the subject. The shorter - matches are all initial substrings of the longer matches. For example, + of the function start at the same point in the subject. The shorter + matches are all initial substrings of the longer matches. For example, if the pattern <.*> @@ -2176,58 +2261,64 @@ MATCHING A PATTERN: THE ALTERNATIVE FUNCTION <something> <something else> <something> <something else> <something further> - On success, the yield of the function is a number greater than zero, - which is the number of matched substrings. The substrings themselves - are returned in ovector. Each string uses two elements; the first is - the offset to the start, and the second is the offset to the end. All - the strings have the same start offset. (Space could have been saved by - giving this only once, but it was decided to retain some compatibility - with the way pcre_exec() returns data, even though the meaning of the - strings is different.) + On success, the yield of the function is a number greater than zero, + which is the number of matched substrings. The substrings themselves + are returned in ovector. Each string uses two elements; the first is + the offset to the start, and the second is the offset to the end. In + fact, all the strings have the same start offset. (Space could have + been saved by giving this only once, but it was decided to retain some + compatibility with the way pcre_exec() returns data, even though the + meaning of the strings is different.) The strings are returned in reverse order of length; that is, the long- - est matching string is given first. If there were too many matches to - fit into ovector, the yield of the function is zero, and the vector is + est matching string is given first. If there were too many matches to + fit into ovector, the yield of the function is zero, and the vector is filled with the longest matches. Error returns from pcre_dfa_exec() - The pcre_dfa_exec() function returns a negative number when it fails. - Many of the errors are the same as for pcre_exec(), and these are - described above. There are in addition the following errors that are + The pcre_dfa_exec() function returns a negative number when it fails. + Many of the errors are the same as for pcre_exec(), and these are + described above. There are in addition the following errors that are specific to pcre_dfa_exec(): PCRE_ERROR_DFA_UITEM (-16) - This return is given if pcre_dfa_exec() encounters an item in the pat- - tern that it does not support, for instance, the use of \C or a back + This return is given if pcre_dfa_exec() encounters an item in the pat- + tern that it does not support, for instance, the use of \C or a back reference. PCRE_ERROR_DFA_UCOND (-17) - This return is given if pcre_dfa_exec() encounters a condition item in - a pattern that uses a back reference for the condition. This is not - supported. + This return is given if pcre_dfa_exec() encounters a condition item + that uses a back reference for the condition, or a test for recursion + in a specific group. These are not supported. PCRE_ERROR_DFA_UMLIMIT (-18) - This return is given if pcre_dfa_exec() is called with an extra block + This return is given if pcre_dfa_exec() is called with an extra block that contains a setting of the match_limit field. This is not supported (it is meaningless). PCRE_ERROR_DFA_WSSIZE (-19) - This return is given if pcre_dfa_exec() runs out of space in the + This return is given if pcre_dfa_exec() runs out of space in the workspace vector. PCRE_ERROR_DFA_RECURSE (-20) - When a recursive subpattern is processed, the matching function calls - itself recursively, using private vectors for ovector and workspace. - This error is given if the output vector is not large enough. This + When a recursive subpattern is processed, the matching function calls + itself recursively, using private vectors for ovector and workspace. + This error is given if the output vector is not large enough. This should be extremely rare, as a vector of size 1000 is used. -Last updated: 08 June 2006 + +SEE ALSO + + pcrebuild(3), pcrecallout(3), pcrecpp(3)(3), pcrematching(3), pcrepar- + tial(3), pcreposix(3), pcreprecompile(3), pcresample(3), pcrestack(3). + +Last updated: 30 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -2401,45 +2492,46 @@ NAME DIFFERENCES BETWEEN PCRE AND PERL This document describes the differences in the ways that PCRE and Perl - handle regular expressions. The differences described here are with - respect to Perl 5.8. + handle regular expressions. The differences described here are mainly + with respect to Perl 5.8, though PCRE version 7.0 contains some fea- + tures that are expected to be in the forthcoming Perl 5.10. - 1. PCRE has only a subset of Perl's UTF-8 and Unicode support. Details - of what it does have are given in the section on UTF-8 support in the + 1. PCRE has only a subset of Perl's UTF-8 and Unicode support. Details + of what it does have are given in the section on UTF-8 support in the main pcre page. 2. PCRE does not allow repeat quantifiers on lookahead assertions. Perl - permits them, but they do not mean what you might think. For example, + permits them, but they do not mean what you might think. For example, (?!a){3} does not assert that the next three characters are not "a". It just asserts that the next character is not "a" three times. - 3. Capturing subpatterns that occur inside negative lookahead asser- - tions are counted, but their entries in the offsets vector are never - set. Perl sets its numerical variables from any such patterns that are + 3. Capturing subpatterns that occur inside negative lookahead asser- + tions are counted, but their entries in the offsets vector are never + set. Perl sets its numerical variables from any such patterns that are matched before the assertion fails to match something (thereby succeed- - ing), but only if the negative lookahead assertion contains just one + ing), but only if the negative lookahead assertion contains just one branch. - 4. Though binary zero characters are supported in the subject string, + 4. Though binary zero characters are supported in the subject string, they are not allowed in a pattern string because it is passed as a nor- mal C string, terminated by zero. The escape sequence \0 can be used in the pattern to represent a binary zero. - 5. The following Perl escape sequences are not supported: \l, \u, \L, + 5. The following Perl escape sequences are not supported: \l, \u, \L, \U, and \N. In fact these are implemented by Perl's general string-han- - dling and are not part of its pattern matching engine. If any of these + dling and are not part of its pattern matching engine. If any of these are encountered by PCRE, an error is generated. - 6. The Perl escape sequences \p, \P, and \X are supported only if PCRE - is built with Unicode character property support. The properties that - can be tested with \p and \P are limited to the general category prop- - erties such as Lu and Nd, script names such as Greek or Han, and the + 6. The Perl escape sequences \p, \P, and \X are supported only if PCRE + is built with Unicode character property support. The properties that + can be tested with \p and \P are limited to the general category prop- + erties such as Lu and Nd, script names such as Greek or Han, and the derived properties Any and L&. 7. PCRE does support the \Q...\E escape for quoting substrings. Charac- - ters in between are treated as literals. This is slightly different - from Perl in that $ and @ are also handled as literals inside the - quotes. In Perl, they cause variable interpolation (but of course PCRE + ters in between are treated as literals. This is slightly different + from Perl in that $ and @ are also handled as literals inside the + quotes. In Perl, they cause variable interpolation (but of course PCRE does not have variables). Note the following examples: Pattern PCRE matches Perl matches @@ -2449,66 +2541,61 @@ DIFFERENCES BETWEEN PCRE AND PERL \Qabc\$xyz\E abc\$xyz abc\$xyz \Qabc\E\$\Qxyz\E abc$xyz abc$xyz - The \Q...\E sequence is recognized both inside and outside character + The \Q...\E sequence is recognized both inside and outside character classes. - 8. Fairly obviously, PCRE does not support the (?{code}) and (?p{code}) - constructions. However, there is support for recursive patterns using - the non-Perl items (?R), (?number), and (?P>name). Also, the PCRE - "callout" feature allows an external function to be called during pat- + 8. Fairly obviously, PCRE does not support the (?{code}) and (??{code}) + constructions. However, there is support for recursive patterns. This + is not available in Perl 5.8, but will be in Perl 5.10. Also, the PCRE + "callout" feature allows an external function to be called during pat- tern matching. See the pcrecallout documentation for details. - 9. There are some differences that are concerned with the settings of - captured strings when part of a pattern is repeated. For example, - matching "aba" against the pattern /^(a(b)?)+$/ in Perl leaves $2 + 9. Subpatterns that are called recursively or as "subroutines" are + always treated as atomic groups in PCRE. This is like Python, but + unlike Perl. + + 10. There are some differences that are concerned with the settings of + captured strings when part of a pattern is repeated. For example, + matching "aba" against the pattern /^(a(b)?)+$/ in Perl leaves $2 unset, but in PCRE it is set to "b". - 10. PCRE provides some extensions to the Perl regular expression facil- - ities: + 11. PCRE provides some extensions to the Perl regular expression facil- + ities. Perl 5.10 will include new features that are not in earlier + versions, some of which (such as named parentheses) have been in PCRE + for some time. This list is with respect to Perl 5.10: - (a) Although lookbehind assertions must match fixed length strings, + (a) Although lookbehind assertions must match fixed length strings, each alternative branch of a lookbehind assertion can match a different length of string. Perl requires them all to have the same length. - (b) If PCRE_DOLLAR_ENDONLY is set and PCRE_MULTILINE is not set, the $ + (b) If PCRE_DOLLAR_ENDONLY is set and PCRE_MULTILINE is not set, the $ meta-character matches only at the very end of the string. (c) If PCRE_EXTRA is set, a backslash followed by a letter with no spe- - cial meaning is faulted. Otherwise, like Perl, the backslash is + cial meaning is faulted. Otherwise, like Perl, the backslash is ignored. (Perl can be made to issue a warning.) - (d) If PCRE_UNGREEDY is set, the greediness of the repetition quanti- + (d) If PCRE_UNGREEDY is set, the greediness of the repetition quanti- fiers is inverted, that is, by default they are not greedy, but if fol- lowed by a question mark they are. (e) PCRE_ANCHORED can be used at matching time to force a pattern to be tried only at the first matching position in the subject string. - (f) The PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, and PCRE_NO_AUTO_CAP- + (f) The PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, and PCRE_NO_AUTO_CAP- TURE options for pcre_exec() have no Perl equivalents. - (g) The (?R), (?number), and (?P>name) constructs allows for recursive - pattern matching (Perl can do this using the (?p{code}) construct, - which PCRE cannot support.) - - (h) PCRE supports named capturing substrings, using the Python syntax. - - (i) PCRE supports the possessive quantifier "++" syntax, taken from - Sun's Java package. + (g) The callout facility is PCRE-specific. - (j) The (R) condition, for testing recursion, is a PCRE extension. + (h) The partial matching facility is PCRE-specific. - (k) The callout facility is PCRE-specific. - - (l) The partial matching facility is PCRE-specific. - - (m) Patterns compiled by PCRE can be saved and re-used at a later time, + (i) Patterns compiled by PCRE can be saved and re-used at a later time, even on different hosts that have the other endianness. - (n) The alternative matching function (pcre_dfa_exec()) matches in a + (j) The alternative matching function (pcre_dfa_exec()) matches in a different way and is not Perl-compatible. -Last updated: 06 June 2006 +Last updated: 28 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -2545,6 +2632,9 @@ PCRE REGULAR EXPRESSION DETAILS function, and how it differs from the normal function, are discussed in the pcrematching page. + +CHARACTERS AND METACHARACTERS + A regular expression is a pattern that is matched against a subject string from left to right. Most characters stand for themselves in a pattern, and match the corresponding characters in the subject. As a @@ -2569,8 +2659,8 @@ PCRE REGULAR EXPRESSION DETAILS There are two different sets of metacharacters: those that are recog- nized anywhere in the pattern except within square brackets, and those - that are recognized in square brackets. Outside square brackets, the - metacharacters are as follows: + that are recognized within square brackets. Outside square brackets, + the metacharacters are as follows: \ general escape character with several uses ^ assert start of string (or line, in multiline mode) @@ -2692,7 +2782,7 @@ BACKSLASH Inside a character class, or if the decimal number is greater than 9 and there have not been that many capturing subpatterns, PCRE re-reads - up to three octal digits following the backslash, ane uses them to gen- + up to three octal digits following the backslash, and uses them to gen- erate a data character. Any subsequent digits stand for themselves. In non-UTF-8 mode, the value of a character specified in octal must be less than \400. In UTF-8 mode, values up to \777 are permitted. For @@ -2719,13 +2809,21 @@ BACKSLASH All the sequences that define a single character value can be used both inside and outside character classes. In addition, inside a character class, the sequence \b is interpreted as the backspace character (hex - 08), and the sequence \X is interpreted as the character "X". Outside a - character class, these sequences have different meanings (see below). + 08), and the sequences \R and \X are interpreted as the characters "R" + and "X", respectively. Outside a character class, these sequences have + different meanings (see below). + + Absolute and relative back references + + The sequence \g followed by a positive or negative number, optionally + enclosed in braces, is an absolute or relative back reference. Back + references are discussed later, following the discussion of parenthe- + sized subpatterns. Generic character types - The third use of backslash is for specifying generic character types. - The following are always recognized: + Another use of backslash is for specifying generic character types. The + following are always recognized: \d any decimal digit \D any character that is not a decimal digit @@ -2762,6 +2860,28 @@ BACKSLASH code character property support is available. The use of locales with Unicode is discouraged. + Newline sequences + + Outside a character class, the escape sequence \R matches any Unicode + newline sequence. This is an extension to Perl. In non-UTF-8 mode \R is + equivalent to the following: + + (?>\r\n|\n|\x0b|\f|\r|\x85) + + This is an example of an "atomic group", details of which are given + below. This particular group matches either the two-character sequence + CR followed by LF, or one of the single characters LF (linefeed, + U+000A), VT (vertical tab, U+000B), FF (formfeed, U+000C), CR (carriage + return, U+000D), or NEL (next line, U+0085). The two-character sequence + is treated as a single unit that cannot be split. + + In UTF-8 mode, two additional characters whose codepoints are greater + than 255 are added: LS (line separator, U+2028) and PS (paragraph sepa- + rator, U+2029). Unicode character property support is not needed for + these characters to be recognized. + + Inside a character class, \R matches the letter "R". + Unicode character properties When PCRE is built with Unicode character property support, three addi- @@ -2788,15 +2908,15 @@ BACKSLASH Those that are not part of an identified script are lumped together as "Common". The current list of scripts is: - Arabic, Armenian, Bengali, Bopomofo, Braille, Buginese, Buhid, Cana- - dian_Aboriginal, Cherokee, Common, Coptic, Cypriot, Cyrillic, Deseret, - Devanagari, Ethiopic, Georgian, Glagolitic, Gothic, Greek, Gujarati, - Gurmukhi, Han, Hangul, Hanunoo, Hebrew, Hiragana, Inherited, Kannada, - Katakana, Kharoshthi, Khmer, Lao, Latin, Limbu, Linear_B, Malayalam, - Mongolian, Myanmar, New_Tai_Lue, Ogham, Old_Italic, Old_Persian, Oriya, - Osmanya, Runic, Shavian, Sinhala, Syloti_Nagri, Syriac, Tagalog, Tag- - banwa, Tai_Le, Tamil, Telugu, Thaana, Thai, Tibetan, Tifinagh, - Ugaritic, Yi. + Arabic, Armenian, Balinese, Bengali, Bopomofo, Braille, Buginese, + Buhid, Canadian_Aboriginal, Cherokee, Common, Coptic, Cuneiform, + Cypriot, Cyrillic, Deseret, Devanagari, Ethiopic, Georgian, Glagolitic, + Gothic, Greek, Gujarati, Gurmukhi, Han, Hangul, Hanunoo, Hebrew, Hira- + gana, Inherited, Kannada, Katakana, Kharoshthi, Khmer, Lao, Latin, + Limbu, Linear_B, Malayalam, Mongolian, Myanmar, New_Tai_Lue, Nko, + Ogham, Old_Italic, Old_Persian, Oriya, Osmanya, Phags_Pa, Phoenician, + Runic, Shavian, Sinhala, Syloti_Nagri, Syriac, Tagalog, Tagbanwa, + Tai_Le, Tamil, Telugu, Thaana, Thai, Tibetan, Tifinagh, Ugaritic, Yi. Each character has exactly one general category property, specified by a two-letter abbreviation. For compatibility with Perl, negation can be @@ -2889,7 +3009,7 @@ BACKSLASH Simple assertions - The fourth use of backslash is for certain simple assertions. An asser- + The final use of backslash is for certain simple assertions. An asser- tion specifies a condition that has to be met at a particular point in a match, without consuming any characters from the subject string. The use of subpatterns for more complicated assertions is described below. @@ -2897,10 +3017,11 @@ BACKSLASH \b matches at a word boundary \B matches when not at a word boundary - \A matches at start of subject - \Z matches at end of subject or before newline at end - \z matches at end of subject - \G matches at first matching position in subject + \A matches at the start of the subject + \Z matches at the end of the subject + also matches before a newline at the end of the subject + \z matches only at the end of the subject + \G matches at the first matching position in the subject These assertions may not appear in character classes (but note that \b has a different meaning, namely the backspace character, inside a char- @@ -2997,30 +3118,34 @@ FULL STOP (PERIOD, DOT) Outside a character class, a dot in the pattern matches any one charac- ter in the subject string except (by default) a character that signi- fies the end of a line. In UTF-8 mode, the matched character may be - more than one byte long. When a line ending is defined as a single - character (CR or LF), dot never matches that character; when the two- - character sequence CRLF is used, dot does not match CR if it is immedi- - ately followed by LF, but otherwise it matches all characters (includ- - ing isolated CRs and LFs). - - The behaviour of dot with regard to newlines can be changed. If the - PCRE_DOTALL option is set, a dot matches any one character, without - exception. If newline is defined as the two-character sequence CRLF, it - takes two dots to match it. - - The handling of dot is entirely independent of the handling of circum- - flex and dollar, the only relationship being that they both involve + more than one byte long. + + When a line ending is defined as a single character, dot never matches + that character; when the two-character sequence CRLF is used, dot does + not match CR if it is immediately followed by LF, but otherwise it + matches all characters (including isolated CRs and LFs). When any Uni- + code line endings are being recognized, dot does not match CR or LF or + any of the other line ending characters. + + The behaviour of dot with regard to newlines can be changed. If the + PCRE_DOTALL option is set, a dot matches any one character, without + exception. If the two-character sequence CRLF is present in the subject + string, it takes two dots to match it. + + The handling of dot is entirely independent of the handling of circum- + flex and dollar, the only relationship being that they both involve newlines. Dot has no special meaning in a character class. MATCHING A SINGLE BYTE Outside a character class, the escape sequence \C matches any one byte, - both in and out of UTF-8 mode. Unlike a dot, it always matches CR and - LF. The feature is provided in Perl in order to match individual bytes - in UTF-8 mode. Because it breaks up UTF-8 characters into individual - bytes, what remains in the string may be a malformed UTF-8 string. For - this reason, the \C escape sequence is best avoided. + both in and out of UTF-8 mode. Unlike a dot, it always matches any + line-ending characters. The feature is provided in Perl in order to + match individual bytes in UTF-8 mode. Because it breaks up UTF-8 char- + acters into individual bytes, what remains in the string may be a mal- + formed UTF-8 string. For this reason, the \C escape sequence is best + avoided. PCRE does not allow \C to appear in lookbehind assertions (described below), because in UTF-8 mode this would make it impossible to calcu- @@ -3067,11 +3192,11 @@ SQUARE BRACKETS AND CHARACTER CLASSES PCRE is compiled with Unicode property support as well as with UTF-8 support. - Characters that might indicate line breaks (CR and LF) are never - treated in any special way when matching character classes, whatever - line-ending sequence is in use, and whatever setting of the PCRE_DOTALL - and PCRE_MULTILINE options is used. A class such as [^a] always matches - one of these characters. + Characters that might indicate line breaks are never treated in any + special way when matching character classes, whatever line-ending + sequence is in use, and whatever setting of the PCRE_DOTALL and + PCRE_MULTILINE options is used. A class such as [^a] always matches one + of these characters. The minus (hyphen) character can be used to specify a range of charac- ters in a character class. For example, [d-m] matches any letter @@ -3203,26 +3328,27 @@ INTERNAL OPTION SETTING PCRE extracts it into the global options (and it will therefore show up in data extracted by the pcre_fullinfo() function). - An option change within a subpattern affects only that part of the cur- - rent pattern that follows it, so + An option change within a subpattern (see below for a description of + subpatterns) affects only that part of the current pattern that follows + it, so (a(?i)b)c matches abc and aBc and no other strings (assuming PCRE_CASELESS is not - used). By this means, options can be made to have different settings - in different parts of the pattern. Any changes made in one alternative - do carry on into subsequent branches within the same subpattern. For + used). By this means, options can be made to have different settings + in different parts of the pattern. Any changes made in one alternative + do carry on into subsequent branches within the same subpattern. For example, (a(?i)b|c) - matches "ab", "aB", "c", and "C", even though when matching "C" the - first branch is abandoned before the option setting. This is because - the effects of option settings happen at compile time. There would be + matches "ab", "aB", "c", and "C", even though when matching "C" the + first branch is abandoned before the option setting. This is because + the effects of option settings happen at compile time. There would be some very weird behaviour otherwise. - The PCRE-specific options PCRE_DUPNAMES, PCRE_UNGREEDY, and PCRE_EXTRA - can be changed in the same way as the Perl-compatible options by using + The PCRE-specific options PCRE_DUPNAMES, PCRE_UNGREEDY, and PCRE_EXTRA + can be changed in the same way as the Perl-compatible options by using the characters J, U and X respectively. @@ -3235,18 +3361,18 @@ SUBPATTERNS cat(aract|erpillar|) - matches one of the words "cat", "cataract", or "caterpillar". Without - the parentheses, it would match "cataract", "erpillar" or the empty + matches one of the words "cat", "cataract", or "caterpillar". Without + the parentheses, it would match "cataract", "erpillar" or an empty string. - 2. It sets up the subpattern as a capturing subpattern. This means - that, when the whole pattern matches, that portion of the subject + 2. It sets up the subpattern as a capturing subpattern. This means + that, when the whole pattern matches, that portion of the subject string that matched the subpattern is passed back to the caller via the - ovector argument of pcre_exec(). Opening parentheses are counted from - left to right (starting from 1) to obtain numbers for the capturing + ovector argument of pcre_exec(). Opening parentheses are counted from + left to right (starting from 1) to obtain numbers for the capturing subpatterns. - For example, if the string "the red king" is matched against the pat- + For example, if the string "the red king" is matched against the pat- tern the ((red|white) (king|queen)) @@ -3254,51 +3380,56 @@ SUBPATTERNS the captured substrings are "red king", "red", and "king", and are num- bered 1, 2, and 3, respectively. - The fact that plain parentheses fulfil two functions is not always - helpful. There are often times when a grouping subpattern is required - without a capturing requirement. If an opening parenthesis is followed - by a question mark and a colon, the subpattern does not do any captur- - ing, and is not counted when computing the number of any subsequent - capturing subpatterns. For example, if the string "the white queen" is + The fact that plain parentheses fulfil two functions is not always + helpful. There are often times when a grouping subpattern is required + without a capturing requirement. If an opening parenthesis is followed + by a question mark and a colon, the subpattern does not do any captur- + ing, and is not counted when computing the number of any subsequent + capturing subpatterns. For example, if the string "the white queen" is matched against the pattern the ((?:red|white) (king|queen)) the captured substrings are "white queen" and "queen", and are numbered - 1 and 2. The maximum number of capturing subpatterns is 65535, and the - maximum depth of nesting of all subpatterns, both capturing and non- - capturing, is 200. + 1 and 2. The maximum number of capturing subpatterns is 65535. - As a convenient shorthand, if any option settings are required at the - start of a non-capturing subpattern, the option letters may appear + As a convenient shorthand, if any option settings are required at the + start of a non-capturing subpattern, the option letters may appear between the "?" and the ":". Thus the two patterns (?i:saturday|sunday) (?:(?i)saturday|sunday) match exactly the same set of strings. Because alternative branches are - tried from left to right, and options are not reset until the end of - the subpattern is reached, an option setting in one branch does affect - subsequent branches, so the above patterns match "SUNDAY" as well as + tried from left to right, and options are not reset until the end of + the subpattern is reached, an option setting in one branch does affect + subsequent branches, so the above patterns match "SUNDAY" as well as "Saturday". NAMED SUBPATTERNS - Identifying capturing parentheses by number is simple, but it can be - very hard to keep track of the numbers in complicated regular expres- - sions. Furthermore, if an expression is modified, the numbers may - change. To help with this difficulty, PCRE supports the naming of sub- - patterns, something that Perl does not provide. The Python syntax - (?P<name>...) is used. References to capturing parentheses from other - parts of the pattern, such as backreferences, recursion, and condi- - tions, can be made by name as well as by number. - - Names consist of up to 32 alphanumeric characters and underscores. - Named capturing parentheses are still allocated numbers as well as - names. The PCRE API provides function calls for extracting the name-to- - number translation table from a compiled pattern. There is also a con- - venience function for extracting a captured substring by name. + Identifying capturing parentheses by number is simple, but it can be + very hard to keep track of the numbers in complicated regular expres- + sions. Furthermore, if an expression is modified, the numbers may + change. To help with this difficulty, PCRE supports the naming of sub- + patterns. This feature was not added to Perl until release 5.10. Python + had the feature earlier, and PCRE introduced it at release 4.0, using + the Python syntax. PCRE now supports both the Perl and the Python syn- + tax. + + In PCRE, a subpattern can be named in one of three ways: (?<name>...) + or (?'name'...) as in Perl, or (?P<name>...) as in Python. References + to capturing parentheses from other parts of the pattern, such as back- + references, recursion, and conditions, can be made by name as well as + by number. + + Names consist of up to 32 alphanumeric characters and underscores. + Named capturing parentheses are still allocated numbers as well as + names, exactly as if the names were not present. The PCRE API provides + function calls for extracting the name-to-number translation table from + a compiled pattern. There is also a convenience function for extracting + a captured substring by name. By default, a name must be unique within a pattern, but it is possible to relax this constraint by setting the PCRE_DUPNAMES option at compile @@ -3308,15 +3439,15 @@ NAMED SUBPATTERNS both cases you want to extract the abbreviation. This pattern (ignoring the line breaks) does the job: - (?P<DN>Mon|Fri|Sun)(?:day)?| - (?P<DN>Tue)(?:sday)?| - (?P<DN>Wed)(?:nesday)?| - (?P<DN>Thu)(?:rsday)?| - (?P<DN>Sat)(?:urday)? + (?<DN>Mon|Fri|Sun)(?:day)?| + (?<DN>Tue)(?:sday)?| + (?<DN>Wed)(?:nesday)?| + (?<DN>Thu)(?:rsday)?| + (?<DN>Sat)(?:urday)? There are five capturing substrings, but only one is ever set after a match. The convenience function for extracting the data by name - returns the substring for the first, and in this example, the only, + returns the substring for the first (and in this example, the only) subpattern of that name that matched. This saves searching to find which numbered subpattern it was. If you make a reference to a non- unique named subpattern from elsewhere in the pattern, the one that @@ -3331,9 +3462,10 @@ REPETITION following items: a literal data character - the . metacharacter + the dot metacharacter the \C escape sequence the \X escape sequence (in UTF-8 mode with Unicode properties) + the \R escape sequence an escape such as \d that matches a single character a character class a back reference (see next section) @@ -3373,8 +3505,8 @@ REPETITION The quantifier {0} is permitted, causing the expression to behave as if the previous item and the quantifier were not present. - For convenience (and historical compatibility) the three most common - quantifiers have single-character abbreviations: + For convenience, the three most common quantifiers have single-charac- + ter abbreviations: * is equivalent to {0,} + is equivalent to {1,} @@ -3426,7 +3558,7 @@ REPETITION which matches one digit by preference, but can match two if that is the only way the rest of the pattern matches. - If the PCRE_UNGREEDY option is set (an option which is not available in + If the PCRE_UNGREEDY option is set (an option that is not available in Perl), the quantifiers are not greedy by default, but individual ones can be made greedy by following them with a question mark. In other words, it inverts the default behaviour. @@ -3437,24 +3569,25 @@ REPETITION minimum or maximum. If a pattern starts with .* or .{0,} and the PCRE_DOTALL option (equiv- - alent to Perl's /s) is set, thus allowing the . to match newlines, the - pattern is implicitly anchored, because whatever follows will be tried - against every character position in the subject string, so there is no - point in retrying the overall match at any position after the first. - PCRE normally treats such a pattern as though it were preceded by \A. - - In cases where it is known that the subject string contains no new- - lines, it is worth setting PCRE_DOTALL in order to obtain this opti- + alent to Perl's /s) is set, thus allowing the dot to match newlines, + the pattern is implicitly anchored, because whatever follows will be + tried against every character position in the subject string, so there + is no point in retrying the overall match at any position after the + first. PCRE normally treats such a pattern as though it were preceded + by \A. + + In cases where it is known that the subject string contains no new- + lines, it is worth setting PCRE_DOTALL in order to obtain this opti- mization, or alternatively using ^ to indicate anchoring explicitly. - However, there is one situation where the optimization cannot be used. - When .* is inside capturing parentheses that are the subject of a - backreference elsewhere in the pattern, a match at the start may fail, - and a later one succeed. Consider, for example: + However, there is one situation where the optimization cannot be used. + When .* is inside capturing parentheses that are the subject of a + backreference elsewhere in the pattern, a match at the start may fail + where a later one succeeds. Consider, for example: (.*)abc\1 - If the subject is "xyz123abc123" the match point is the fourth charac- + If the subject is "xyz123abc123" the match point is the fourth charac- ter. For this reason, such a pattern is not implicitly anchored. When a capturing subpattern is repeated, the value captured is the sub- @@ -3463,8 +3596,8 @@ REPETITION (tweedle[dume]{3}\s*)+ has matched "tweedledum tweedledee" the value of the captured substring - is "tweedledee". However, if there are nested capturing subpatterns, - the corresponding captured values may have been set in previous itera- + is "tweedledee". However, if there are nested capturing subpatterns, + the corresponding captured values may have been set in previous itera- tions. For example, after /(a|(b))+/ @@ -3474,12 +3607,13 @@ REPETITION ATOMIC GROUPING AND POSSESSIVE QUANTIFIERS - With both maximizing and minimizing repetition, failure of what follows - normally causes the repeated item to be re-evaluated to see if a dif- - ferent number of repeats allows the rest of the pattern to match. Some- - times it is useful to prevent this, either to change the nature of the - match, or to cause it fail earlier than it otherwise might, when the - author of the pattern knows there is no point in carrying on. + With both maximizing ("greedy") and minimizing ("ungreedy" or "lazy") + repetition, failure of what follows normally causes the repeated item + to be re-evaluated to see if a different number of repeats allows the + rest of the pattern to match. Sometimes it is useful to prevent this, + either to change the nature of the match, or to cause it fail earlier + than it otherwise might, when the author of the pattern knows there is + no point in carrying on. Consider, for example, the pattern \d+foo when applied to the subject line @@ -3493,10 +3627,9 @@ ATOMIC GROUPING AND POSSESSIVE QUANTIFIERS the means for specifying that once a subpattern has matched, it is not to be re-evaluated in this way. - If we use atomic grouping for the previous example, the matcher would - give up immediately on failing to match "foo" the first time. The nota- - tion is a kind of special parenthesis, starting with (?> as in this - example: + If we use atomic grouping for the previous example, the matcher gives + up immediately on failing to match "foo" the first time. The notation + is a kind of special parenthesis, starting with (?> as in this example: (?>\d+)foo @@ -3528,63 +3661,95 @@ ATOMIC GROUPING AND POSSESSIVE QUANTIFIERS Possessive quantifiers are always greedy; the setting of the PCRE_UNGREEDY option is ignored. They are a convenient notation for the simpler forms of atomic group. However, there is no difference in the - meaning or processing of a possessive quantifier and the equivalent - atomic group. - - The possessive quantifier syntax is an extension to the Perl syntax. - Jeffrey Friedl originated the idea (and the name) in the first edition - of his book. Mike McCloskey liked it, so implemented it when he built - Sun's Java package, and PCRE copied it from there. - - When a pattern contains an unlimited repeat inside a subpattern that - can itself be repeated an unlimited number of times, the use of an - atomic group is the only way to avoid some failing matches taking a + meaning of a possessive quantifier and the equivalent atomic group, + though there may be a performance difference; possessive quantifiers + should be slightly faster. + + The possessive quantifier syntax is an extension to the Perl 5.8 syn- + tax. Jeffrey Friedl originated the idea (and the name) in the first + edition of his book. Mike McCloskey liked it, so implemented it when he + built Sun's Java package, and PCRE copied it from there. It ultimately + found its way into Perl at release 5.10. + + PCRE has an optimization that automatically "possessifies" certain sim- + ple pattern constructs. For example, the sequence A+B is treated as + A++B because there is no point in backtracking into a sequence of A's + when B must follow. + + When a pattern contains an unlimited repeat inside a subpattern that + can itself be repeated an unlimited number of times, the use of an + atomic group is the only way to avoid some failing matches taking a very long time indeed. The pattern (\D+|<\d+>)*[!?] - matches an unlimited number of substrings that either consist of non- - digits, or digits enclosed in <>, followed by either ! or ?. When it + matches an unlimited number of substrings that either consist of non- + digits, or digits enclosed in <>, followed by either ! or ?. When it matches, it runs quickly. However, if it is applied to aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa - it takes a long time before reporting failure. This is because the - string can be divided between the internal \D+ repeat and the external - * repeat in a large number of ways, and all have to be tried. (The - example uses [!?] rather than a single character at the end, because - both PCRE and Perl have an optimization that allows for fast failure - when a single character is used. They remember the last single charac- - ter that is required for a match, and fail early if it is not present - in the string.) If the pattern is changed so that it uses an atomic + it takes a long time before reporting failure. This is because the + string can be divided between the internal \D+ repeat and the external + * repeat in a large number of ways, and all have to be tried. (The + example uses [!?] rather than a single character at the end, because + both PCRE and Perl have an optimization that allows for fast failure + when a single character is used. They remember the last single charac- + ter that is required for a match, and fail early if it is not present + in the string.) If the pattern is changed so that it uses an atomic group, like this: ((?>\D+)|<\d+>)*[!?] - sequences of non-digits cannot be broken, and failure happens quickly. + sequences of non-digits cannot be broken, and failure happens quickly. BACK REFERENCES Outside a character class, a backslash followed by a digit greater than 0 (and possibly further digits) is a back reference to a capturing sub- - pattern earlier (that is, to its left) in the pattern, provided there + pattern earlier (that is, to its left) in the pattern, provided there have been that many previous capturing left parentheses. However, if the decimal number following the backslash is less than 10, - it is always taken as a back reference, and causes an error only if - there are not that many capturing left parentheses in the entire pat- - tern. In other words, the parentheses that are referenced need not be - to the left of the reference for numbers less than 10. A "forward back - reference" of this type can make sense when a repetition is involved - and the subpattern to the right has participated in an earlier itera- + it is always taken as a back reference, and causes an error only if + there are not that many capturing left parentheses in the entire pat- + tern. In other words, the parentheses that are referenced need not be + to the left of the reference for numbers less than 10. A "forward back + reference" of this type can make sense when a repetition is involved + and the subpattern to the right has participated in an earlier itera- tion. - It is not possible to have a numerical "forward back reference" to sub- - pattern whose number is 10 or more. However, a back reference to any - subpattern is possible using named parentheses (see below). See also - the subsection entitled "Non-printing characters" above for further - details of the handling of digits following a backslash. + It is not possible to have a numerical "forward back reference" to a + subpattern whose number is 10 or more using this syntax because a + sequence such as \50 is interpreted as a character defined in octal. + See the subsection entitled "Non-printing characters" above for further + details of the handling of digits following a backslash. There is no + such problem when named parentheses are used. A back reference to any + subpattern is possible using named parentheses (see below). + + Another way of avoiding the ambiguity inherent in the use of digits + following a backslash is to use the \g escape sequence, which is a fea- + ture introduced in Perl 5.10. This escape must be followed by a posi- + tive or a negative number, optionally enclosed in braces. These exam- + ples are all identical: + + (ring), \1 + (ring), \g1 + (ring), \g{1} + + A positive number specifies an absolute reference without the ambiguity + that is present in the older syntax. It is also useful when literal + digits follow the reference. A negative number is a relative reference. + Consider this example: + + (abc(def)ghi)\g{-1} + + The sequence \g{-1} is a reference to the most recently started captur- + ing subpattern before \g, that is, is it equivalent to \2. Similarly, + \g{-2} would be equivalent to \1. The use of relative references can be + helpful in long patterns, and also in patterns that are created by + joining together fragments that contain references within themselves. A back reference matches whatever actually matched the capturing sub- pattern in the current subject string, rather than anything matching @@ -3603,62 +3768,64 @@ BACK REFERENCES matches "rah rah" and "RAH RAH", but not "RAH rah", even though the original capturing subpattern is matched caselessly. - Back references to named subpatterns use the Python syntax (?P=name). - We could rewrite the above example as follows: + Back references to named subpatterns use the Perl syntax \k<name> or + \k'name' or the Python syntax (?P=name). We could rewrite the above + example in either of the following ways: + (?<p1>(?i)rah)\s+\k<p1> (?P<p1>(?i)rah)\s+(?P=p1) - A subpattern that is referenced by name may appear in the pattern + A subpattern that is referenced by name may appear in the pattern before or after the reference. - There may be more than one back reference to the same subpattern. If a - subpattern has not actually been used in a particular match, any back + There may be more than one back reference to the same subpattern. If a + subpattern has not actually been used in a particular match, any back references to it always fail. For example, the pattern (a|(bc))\2 - always fails if it starts to match "a" rather than "bc". Because there - may be many capturing parentheses in a pattern, all digits following - the backslash are taken as part of a potential back reference number. + always fails if it starts to match "a" rather than "bc". Because there + may be many capturing parentheses in a pattern, all digits following + the backslash are taken as part of a potential back reference number. If the pattern continues with a digit character, some delimiter must be - used to terminate the back reference. If the PCRE_EXTENDED option is - set, this can be whitespace. Otherwise an empty comment (see "Com- + used to terminate the back reference. If the PCRE_EXTENDED option is + set, this can be whitespace. Otherwise an empty comment (see "Com- ments" below) can be used. - A back reference that occurs inside the parentheses to which it refers - fails when the subpattern is first used, so, for example, (a\1) never - matches. However, such references can be useful inside repeated sub- + A back reference that occurs inside the parentheses to which it refers + fails when the subpattern is first used, so, for example, (a\1) never + matches. However, such references can be useful inside repeated sub- patterns. For example, the pattern (a|b\1)+ matches any number of "a"s and also "aba", "ababbaa" etc. At each iter- - ation of the subpattern, the back reference matches the character - string corresponding to the previous iteration. In order for this to - work, the pattern must be such that the first iteration does not need - to match the back reference. This can be done using alternation, as in + ation of the subpattern, the back reference matches the character + string corresponding to the previous iteration. In order for this to + work, the pattern must be such that the first iteration does not need + to match the back reference. This can be done using alternation, as in the example above, or by a quantifier with a minimum of zero. ASSERTIONS - An assertion is a test on the characters following or preceding the - current matching point that does not actually consume any characters. - The simple assertions coded as \b, \B, \A, \G, \Z, \z, ^ and $ are + An assertion is a test on the characters following or preceding the + current matching point that does not actually consume any characters. + The simple assertions coded as \b, \B, \A, \G, \Z, \z, ^ and $ are described above. - More complicated assertions are coded as subpatterns. There are two - kinds: those that look ahead of the current position in the subject - string, and those that look behind it. An assertion subpattern is - matched in the normal way, except that it does not cause the current + More complicated assertions are coded as subpatterns. There are two + kinds: those that look ahead of the current position in the subject + string, and those that look behind it. An assertion subpattern is + matched in the normal way, except that it does not cause the current matching position to be changed. - Assertion subpatterns are not capturing subpatterns, and may not be - repeated, because it makes no sense to assert the same thing several - times. If any kind of assertion contains capturing subpatterns within - it, these are counted for the purposes of numbering the capturing sub- + Assertion subpatterns are not capturing subpatterns, and may not be + repeated, because it makes no sense to assert the same thing several + times. If any kind of assertion contains capturing subpatterns within + it, these are counted for the purposes of numbering the capturing sub- patterns in the whole pattern. However, substring capturing is carried - out only for positive assertions, because it does not make sense for + out only for positive assertions, because it does not make sense for negative assertions. Lookahead assertions @@ -3668,37 +3835,37 @@ ASSERTIONS \w+(?=;) - matches a word followed by a semicolon, but does not include the semi- + matches a word followed by a semicolon, but does not include the semi- colon in the match, and foo(?!bar) - matches any occurrence of "foo" that is not followed by "bar". Note + matches any occurrence of "foo" that is not followed by "bar". Note that the apparently similar pattern (?!foo)bar - does not find an occurrence of "bar" that is preceded by something - other than "foo"; it finds any occurrence of "bar" whatsoever, because + does not find an occurrence of "bar" that is preceded by something + other than "foo"; it finds any occurrence of "bar" whatsoever, because the assertion (?!foo) is always true when the next three characters are "bar". A lookbehind assertion is needed to achieve the other effect. If you want to force a matching failure at some point in a pattern, the - most convenient way to do it is with (?!) because an empty string - always matches, so an assertion that requires there not to be an empty + most convenient way to do it is with (?!) because an empty string + always matches, so an assertion that requires there not to be an empty string must always fail. Lookbehind assertions - Lookbehind assertions start with (?<= for positive assertions and (?<! + Lookbehind assertions start with (?<= for positive assertions and (?<! for negative assertions. For example, (?<!foo)bar - does find an occurrence of "bar" that is not preceded by "foo". The - contents of a lookbehind assertion are restricted such that all the + does find an occurrence of "bar" that is not preceded by "foo". The + contents of a lookbehind assertion are restricted such that all the strings it matches must have a fixed length. However, if there are sev- - eral top-level alternatives, they do not all have to have the same + eral top-level alternatives, they do not all have to have the same fixed length. Thus (?<=bullock|donkey) @@ -3707,59 +3874,55 @@ ASSERTIONS (?<!dogs?|cats?) - causes an error at compile time. Branches that match different length - strings are permitted only at the top level of a lookbehind assertion. - This is an extension compared with Perl (at least for 5.8), which - requires all branches to match the same length of string. An assertion + causes an error at compile time. Branches that match different length + strings are permitted only at the top level of a lookbehind assertion. + This is an extension compared with Perl (at least for 5.8), which + requires all branches to match the same length of string. An assertion such as (?<=ab(c|de)) - is not permitted, because its single top-level branch can match two - different lengths, but it is acceptable if rewritten to use two top- + is not permitted, because its single top-level branch can match two + different lengths, but it is acceptable if rewritten to use two top- level branches: (?<=abc|abde) - The implementation of lookbehind assertions is, for each alternative, - to temporarily move the current position back by the fixed width and + The implementation of lookbehind assertions is, for each alternative, + to temporarily move the current position back by the fixed length and then try to match. If there are insufficient characters before the cur- - rent position, the match is deemed to fail. + rent position, the assertion fails. PCRE does not allow the \C escape (which matches a single byte in UTF-8 - mode) to appear in lookbehind assertions, because it makes it impossi- - ble to calculate the length of the lookbehind. The \X escape, which can - match different numbers of bytes, is also not permitted. + mode) to appear in lookbehind assertions, because it makes it impossi- + ble to calculate the length of the lookbehind. The \X and \R escapes, + which can match different numbers of bytes, are also not permitted. - Atomic groups can be used in conjunction with lookbehind assertions to - specify efficient matching at the end of the subject string. Consider a - simple pattern such as + Possessive quantifiers can be used in conjunction with lookbehind + assertions to specify efficient matching at the end of the subject + string. Consider a simple pattern such as abcd$ - when applied to a long string that does not match. Because matching + when applied to a long string that does not match. Because matching proceeds from left to right, PCRE will look for each "a" in the subject - and then see if what follows matches the rest of the pattern. If the + and then see if what follows matches the rest of the pattern. If the pattern is specified as ^.*abcd$ - the initial .* matches the entire string at first, but when this fails + the initial .* matches the entire string at first, but when this fails (because there is no following "a"), it backtracks to match all but the - last character, then all but the last two characters, and so on. Once - again the search for "a" covers the entire string, from right to left, + last character, then all but the last two characters, and so on. Once + again the search for "a" covers the entire string, from right to left, so we are no better off. However, if the pattern is written as - ^(?>.*)(?<=abcd) - - or, equivalently, using the possessive quantifier syntax, - ^.*+(?<=abcd) - there can be no backtracking for the .* item; it can match only the - entire string. The subsequent lookbehind assertion does a single test - on the last four characters. If it fails, the match fails immediately. - For long strings, this approach makes a significant difference to the + there can be no backtracking for the .*+ item; it can match only the + entire string. The subsequent lookbehind assertion does a single test + on the last four characters. If it fails, the match fails immediately. + For long strings, this approach makes a significant difference to the processing time. Using multiple assertions @@ -3768,18 +3931,18 @@ ASSERTIONS (?<=\d{3})(?<!999)foo - matches "foo" preceded by three digits that are not "999". Notice that - each of the assertions is applied independently at the same point in - the subject string. First there is a check that the previous three - characters are all digits, and then there is a check that the same + matches "foo" preceded by three digits that are not "999". Notice that + each of the assertions is applied independently at the same point in + the subject string. First there is a check that the previous three + characters are all digits, and then there is a check that the same three characters are not "999". This pattern does not match "foo" pre- - ceded by six characters, the first of which are digits and the last - three of which are not "999". For example, it doesn't match "123abc- + ceded by six characters, the first of which are digits and the last + three of which are not "999". For example, it doesn't match "123abc- foo". A pattern to do that is (?<=\d{3}...)(?<!999)foo - This time the first assertion looks at the preceding six characters, + This time the first assertion looks at the preceding six characters, checking that the first three are digits, and then the second assertion checks that the preceding three characters are not "999". @@ -3787,39 +3950,38 @@ ASSERTIONS (?<=(?<!foo)bar)baz - matches an occurrence of "baz" that is preceded by "bar" which in turn + matches an occurrence of "baz" that is preceded by "bar" which in turn is not preceded by "foo", while (?<=\d{3}(?!999)...)foo - is another pattern that matches "foo" preceded by three digits and any + is another pattern that matches "foo" preceded by three digits and any three characters that are not "999". CONDITIONAL SUBPATTERNS - It is possible to cause the matching process to obey a subpattern con- - ditionally or to choose between two alternative subpatterns, depending - on the result of an assertion, or whether a previous capturing subpat- - tern matched or not. The two possible forms of conditional subpattern + It is possible to cause the matching process to obey a subpattern con- + ditionally or to choose between two alternative subpatterns, depending + on the result of an assertion, or whether a previous capturing subpat- + tern matched or not. The two possible forms of conditional subpattern are (?(condition)yes-pattern) (?(condition)yes-pattern|no-pattern) - If the condition is satisfied, the yes-pattern is used; otherwise the - no-pattern (if present) is used. If there are more than two alterna- + If the condition is satisfied, the yes-pattern is used; otherwise the + no-pattern (if present) is used. If there are more than two alterna- tives in the subpattern, a compile-time error occurs. - There are three kinds of condition. If the text between the parentheses - consists of a sequence of digits, or a sequence of alphanumeric charac- - ters and underscores, the condition is satisfied if the capturing sub- - pattern of that number or name has previously matched. There is a pos- - sible ambiguity here, because subpattern names may consist entirely of - digits. PCRE looks first for a named subpattern; if it cannot find one - and the text consists entirely of digits, it looks for a subpattern of - that number, which must be greater than zero. Using subpattern names - that consist entirely of digits is not recommended. + There are four kinds of condition: references to subpatterns, refer- + ences to recursion, a pseudo-condition called DEFINE, and assertions. + + Checking for a used subpattern by number + + If the text between the parentheses consists of a sequence of digits, + the condition is true if the capturing subpattern of that number has + previously matched. Consider the following pattern, which contains non-significant white space to make it more readable (assume the PCRE_EXTENDED option) and to @@ -3836,18 +3998,68 @@ CONDITIONAL SUBPATTERNS tern is executed and a closing parenthesis is required. Otherwise, since no-pattern is not present, the subpattern matches nothing. In other words, this pattern matches a sequence of non-parentheses, - optionally enclosed in parentheses. Rewriting it to use a named subpat- - tern gives this: + optionally enclosed in parentheses. + + Checking for a used subpattern by name + + Perl uses the syntax (?(<name>)...) or (?('name')...) to test for a + used subpattern by name. For compatibility with earlier versions of + PCRE, which had this facility before Perl, the syntax (?(name)...) is + also recognized. However, there is a possible ambiguity with this syn- + tax, because subpattern names may consist entirely of digits. PCRE + looks first for a named subpattern; if it cannot find one and the name + consists entirely of digits, PCRE looks for a subpattern of that num- + ber, which must be greater than zero. Using subpattern names that con- + sist entirely of digits is not recommended. + + Rewriting the above example to use a named subpattern gives this: + + (?<OPEN> \( )? [^()]+ (?(<OPEN>) \) ) + - (?P<OPEN> \( )? [^()]+ (?(OPEN) \) ) + Checking for pattern recursion If the condition is the string (R), and there is no subpattern with the - name R, the condition is satisfied if a recursive call to the pattern - or subpattern has been made. At "top level", the condition is false. - This is a PCRE extension. Recursive patterns are described in the next - section. + name R, the condition is true if a recursive call to the whole pattern + or any subpattern has been made. If digits or a name preceded by amper- + sand follow the letter R, for example: + + (?(R3)...) or (?(R&name)...) + + the condition is true if the most recent recursion is into the subpat- + tern whose number or name is given. This condition does not check the + entire recursion stack. + + At "top level", all these recursion test conditions are false. Recur- + sive patterns are described below. + + Defining subpatterns for use by reference only + + If the condition is the string (DEFINE), and there is no subpattern + with the name DEFINE, the condition is always false. In this case, + there may be only one alternative in the subpattern. It is always + skipped if control reaches this point in the pattern; the idea of + DEFINE is that it can be used to define "subroutines" that can be ref- + erenced from elsewhere. (The use of "subroutines" is described below.) + For example, a pattern to match an IPv4 address could be written like + this (ignore whitespace and line breaks): + + (?(DEFINE) (?<byte> 2[0-4]\d | 25[0-5] | 1\d\d | [1-9]?\d) ) + \b (?&byte) (\.(?&byte)){3} \b + + The first part of the pattern is a DEFINE group inside which a another + group named "byte" is defined. This matches an individual component of + an IPv4 address (a number less than 256). When matching takes place, + this part of the pattern is skipped because DEFINE acts like a false + condition. - If the condition is not a sequence of digits or (R), it must be an + The rest of the pattern uses references to the named group to match the + four dot-separated components of an IPv4 address, insisting on a word + boundary at each end. + + Assertion conditions + + If the condition is not in any of the above formats, it must be an assertion. This may be a positive or negative lookahead or lookbehind assertion. Consider this pattern, again containing non-significant white space, and with the two alternatives on the second line: @@ -3882,110 +4094,116 @@ RECURSIVE PATTERNS unlimited nested parentheses. Without the use of recursion, the best that can be done is to use a pattern that matches up to some fixed depth of nesting. It is not possible to handle an arbitrary nesting - depth. Perl provides a facility that allows regular expressions to - recurse (amongst other things). It does this by interpolating Perl code - in the expression at run time, and the code can refer to the expression - itself. A Perl pattern to solve the parentheses problem can be created - like this: + depth. + + For some time, Perl has provided a facility that allows regular expres- + sions to recurse (amongst other things). It does this by interpolating + Perl code in the expression at run time, and the code can refer to the + expression itself. A Perl pattern using code interpolation to solve the + parentheses problem can be created like this: $re = qr{\( (?: (?>[^()]+) | (?p{$re}) )* \)}x; The (?p{...}) item interpolates Perl code at run time, and in this case - refers recursively to the pattern in which it appears. Obviously, PCRE - cannot support the interpolation of Perl code. Instead, it supports - some special syntax for recursion of the entire pattern, and also for - individual subpattern recursion. + refers recursively to the pattern in which it appears. + + 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. - The special item that consists of (? followed by a number greater than + A special item that consists of (? followed by a number greater than zero and a closing parenthesis is a recursive call of the subpattern of - the given number, provided that it occurs inside that subpattern. (If - not, it is a "subroutine" call, which is described in the next sec- - tion.) The special item (?R) is a recursive call of the entire regular - expression. + the given number, provided that it occurs inside that subpattern. (If + not, it is a "subroutine" call, which is described in the next sec- + tion.) The special item (?R) or (?0) is a recursive call of the entire + regular expression. - 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 subse- - quent matching failure. + 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 PCRE pattern solves the nested parentheses problem (assume the + This PCRE pattern solves the nested parentheses problem (assume the PCRE_EXTENDED option is set so that white space is ignored): \( ( (?>[^()]+) | (?R) )* \) - First it matches an opening parenthesis. Then it matches any number of - substrings which can either be a sequence of non-parentheses, or a - recursive match of the pattern itself (that is, a correctly parenthe- + First it matches an opening parenthesis. Then it matches any number of + substrings which can either be a sequence of non-parentheses, or a + recursive match of the pattern itself (that is, a correctly parenthe- sized substring). Finally there is a closing parenthesis. - If this were part of a larger pattern, you would not want to recurse + If this were part of a larger pattern, you would not want to recurse the entire pattern, so instead you could use this: ( \( ( (?>[^()]+) | (?1) )* \) ) - We have put the pattern into parentheses, and caused the recursion to - refer to them instead of the whole pattern. In a larger pattern, keep- - ing track of parenthesis numbers can be tricky. It may be more conve- - nient to use named parentheses instead. For this, PCRE uses (?P>name), - which is an extension to the Python syntax that PCRE uses for named - parentheses (Perl does not provide named parentheses). We could rewrite - the above example as follows: + We have put the pattern into parentheses, and caused the recursion to + refer to them instead of the whole pattern. In a larger pattern, keep- + ing track of parenthesis numbers can be tricky. It may be more conve- + nient to use named parentheses instead. The Perl syntax for this is + (?&name); PCRE's earlier syntax (?P>name) is also supported. We could + rewrite the above example as follows: - (?P<pn> \( ( (?>[^()]+) | (?P>pn) )* \) ) + (?<pn> \( ( (?>[^()]+) | (?&pn) )* \) ) - This particular example pattern contains nested unlimited repeats, and - so the use of atomic grouping for matching strings of non-parentheses - is important when applying the pattern to strings that do not match. - For example, when this pattern is applied to + If there is more than one subpattern with the same name, the earliest + one is used. This particular example pattern contains nested unlimited + repeats, and so the use of atomic grouping for matching strings of non- + parentheses is important when applying the pattern to strings that do + not match. For example, when this pattern is applied to (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa() - it yields "no match" quickly. However, if atomic grouping is not used, - the match runs for a very long time indeed because there are so many - different ways the + and * repeats can carve up the subject, and all + it yields "no match" quickly. However, if atomic grouping is not used, + the match runs for a very long time indeed because there are so many + different ways the + and * repeats can carve up the subject, and all have to be tested before failure can be reported. At the end of a match, the values set for any capturing subpatterns are those from the outermost level of the recursion at which the subpattern - value is set. If you want to obtain intermediate values, a callout - function can be used (see the next section and the pcrecallout documen- - tation). If the pattern above is matched against + value is set. If you want to obtain intermediate values, a callout + function can be used (see below and the pcrecallout documentation). If + the pattern above is matched against (ab(cd)ef) - the value for the capturing parentheses is "ef", which is the last - value taken on at the top level. If additional parentheses are added, + the value for the capturing parentheses is "ef", which is the last + value taken on at the top level. If additional parentheses are added, giving \( ( ( (?>[^()]+) | (?R) )* ) \) ^ ^ ^ ^ - the string they capture is "ab(cd)ef", the contents of the top level - parentheses. If there are more than 15 capturing parentheses in a pat- + the string they capture is "ab(cd)ef", the contents of the top level + parentheses. If there are more than 15 capturing parentheses in a pat- tern, PCRE has to obtain extra memory to store data during a recursion, - which it does by using pcre_malloc, freeing it via pcre_free after- - wards. If no memory can be obtained, the match fails with the + which it does by using pcre_malloc, freeing it via pcre_free after- + wards. If no memory can be obtained, the match fails with the PCRE_ERROR_NOMEMORY error. - Do not confuse the (?R) item with the condition (R), which tests for - recursion. Consider this pattern, which matches text in angle brack- - ets, allowing for arbitrary nesting. Only digits are allowed in nested - brackets (that is, when recursing), whereas any characters are permit- + Do not confuse the (?R) item with the condition (R), which tests for + recursion. Consider this pattern, which matches text in angle brack- + ets, allowing for arbitrary nesting. Only digits are allowed in nested + brackets (that is, when recursing), whereas any characters are permit- ted at the outer level. < (?: (?(R) \d++ | [^<>]*+) | (?R)) * > - In this pattern, (?(R) is the start of a conditional subpattern, with - two different alternatives for the recursive and non-recursive cases. + 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. SUBPATTERNS AS SUBROUTINES If the syntax for a recursive subpattern reference (either by number or - by name) is used outside the parentheses to which it refers, it oper- - ates like a subroutine in a programming language. An earlier example + by name) is used outside the parentheses to which it refers, it oper- + ates like a subroutine in a programming language. The "called" subpat- + tern may be defined before or after the reference. An earlier example pointed out that the pattern (sens|respons)e and \1ibility @@ -3996,15 +4214,23 @@ SUBPATTERNS AS SUBROUTINES (sens|respons)e and (?1)ibility is used, it does match "sense and responsibility" as well as the other - two strings. Such references, if given numerically, must follow the - subpattern to which they refer. However, named references can refer to - later subpatterns. + two strings. Another example is given in the discussion of DEFINE + above. Like recursive subpatterns, a "subroutine" 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 + 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. + When a subpattern is used as a subroutine, processing options such as + case-independence are fixed when the subpattern is defined. They cannot + be changed for different calls. For example, consider this pattern: + + (abc)(?i:(?1)) + + It matches "abcabc". It does not match "abcABC" because the change of + processing option does not affect the called subpattern. + CALLOUTS @@ -4040,7 +4266,12 @@ CALLOUTS gether. A complete description of the interface to the callout function is given in the pcrecallout documentation. -Last updated: 06 June 2006 + +SEE ALSO + + pcreapi(3), pcrecallout(3), pcrematching(3), pcre(3). + +Last updated: 06 December 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -4146,8 +4377,8 @@ EXAMPLE OF PARTIAL MATCHING USING PCRETEST The first data string is matched completely, so pcretest shows the matched substrings. The remaining four strings do not match the com- plete pattern, but the first two are partial matches. The same test, - using DFA matching (by means of the \D escape sequence), produces the - following output: + using pcre_dfa_exec() matching (by means of the \D escape sequence), + produces the following output: re> /^?(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)$/ data> 25jun04\P\D @@ -4169,11 +4400,12 @@ MULTI-SEGMENT MATCHING WITH pcre_dfa_exec() When a partial match has been found using pcre_dfa_exec(), it is possi- ble to continue the match by providing additional subject data and - calling pcre_dfa_exec() again with the PCRE_DFA_RESTART option and the - same working space (where details of the previous partial match are - stored). Here is an example using pcretest, where the \R escape - sequence sets the PCRE_DFA_RESTART option and the \D escape sequence - requests the use of pcre_dfa_exec(): + calling pcre_dfa_exec() again with the same compiled regular expres- + sion, this time setting the PCRE_DFA_RESTART option. You must also pass + the same working space as before, because this is where details of the + previous partial match are stored. Here is an example using pcretest, + using the \R escape sequence to set the PCRE_DFA_RESTART option (\P and + \D are as above): re> /^?(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)$/ data> 23ja\P\D @@ -4181,16 +4413,17 @@ MULTI-SEGMENT MATCHING WITH pcre_dfa_exec() data> n05\R\D 0: n05 - The first call has "23ja" as the subject, and requests partial match- - ing; the second call has "n05" as the subject for the continued - (restarted) match. Notice that when the match is complete, only the - last part is shown; PCRE does not retain the previously partially- - matched string. It is up to the calling program to do that if it needs + The first call has "23ja" as the subject, and requests partial match- + ing; the second call has "n05" as the subject for the continued + (restarted) match. Notice that when the match is complete, only the + last part is shown; PCRE does not retain the previously partially- + matched string. It is up to the calling program to do that if it needs to. - This facility can be used to pass very long subject strings to - pcre_dfa_exec(). However, some care is needed for certain types of pat- - tern. + You can set PCRE_PARTIAL with PCRE_DFA_RESTART to continue partial + matching over multiple segments. This facility can be used to pass very + long subject strings to pcre_dfa_exec(). However, some care is needed + for certain types of pattern. 1. If the pattern contains tests for the beginning or end of a line, you need to pass the PCRE_NOTBOL or PCRE_NOTEOL options, as appropri- @@ -4199,7 +4432,7 @@ MULTI-SEGMENT MATCHING WITH pcre_dfa_exec() 2. If the pattern contains backward assertions (including \b or \B), you need to arrange for some overlap in the subject strings to allow - for this. For example, you could pass the subject in chunks that were + for this. For example, you could pass the subject in chunks that are 500 bytes long, but in a buffer of 700 bytes, with the starting offset set to 200 and the previous 200 bytes at the start of the buffer. @@ -4249,7 +4482,7 @@ MULTI-SEGMENT MATCHING WITH pcre_dfa_exec() where no string can be a partial match for both alternatives. -Last updated: 16 January 2006 +Last updated: 30 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -4361,14 +4594,17 @@ COMPATIBILITY WITH DIFFERENT PCRE RELEASES makes up a compiled pattern was changed for release 5.0. If you have any saved patterns that were compiled with previous releases (not a facility that was previously advertised), you will have to recompile - them for release 5.0. However, from now on, it should be possible to - make changes in a compatible manner. + them for release 5.0 and above. + + If you have any saved patterns in UTF-8 mode that use \p or \P that + were compiled with any release up to and including 6.4, you will have + to recompile them for release 6.5 and above. - Notwithstanding the above, if you have any saved patterns in UTF-8 mode - that use \p or \P that were compiled with any release up to and includ- - ing 6.4, you will have to recompile them for release 6.5 and above. + All saved patterns from earlier releases must be recompiled for release + 7.0 or higher, because there was an internal reorganization at that + release. -Last updated: 01 February 2006 +Last updated: 28 November 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -4382,14 +4618,70 @@ NAME PCRE PERFORMANCE - Certain items that may appear in regular expression patterns are more - efficient than others. It is more efficient to use a character class - like [aeiou] than a set of alternatives such as (a|e|i|o|u). In gen- - eral, the simplest construction that provides the required behaviour is - usually the most efficient. Jeffrey Friedl's book contains a lot of - useful general discussion about optimizing regular expressions for - efficient performance. This document contains a few observations about - PCRE. + Two aspects of performance are discussed below: memory usage and pro- + cessing time. The way you express your pattern as a regular expression + can affect both of them. + + +MEMORY USAGE + + Patterns are compiled by PCRE into a reasonably efficient byte code, so + that most simple patterns do not use much memory. However, there is one + case where memory usage can be unexpectedly large. When a parenthesized + subpattern has a quantifier with a minimum greater than 1 and/or a lim- + ited maximum, the whole subpattern is repeated in the compiled code. + For example, the pattern + + (abc|def){2,4} + + is compiled as if it were + + (abc|def)(abc|def)((abc|def)(abc|def)?)? + + (Technical aside: It is done this way so that backtrack points within + each of the repetitions can be independently maintained.) + + For regular expressions whose quantifiers use only small numbers, this + is not usually a problem. However, if the numbers are large, and par- + ticularly if such repetitions are nested, the memory usage can become + an embarrassment. For example, the very simple pattern + + ((ab){1,1000}c){1,3} + + uses 51K bytes when compiled. When PCRE is compiled with its default + internal pointer size of two bytes, the size limit on a compiled pat- + tern is 64K, and this is reached with the above pattern if the outer + repetition is increased from 3 to 4. PCRE can be compiled to use larger + internal pointers and thus handle larger compiled patterns, but it is + better to try to rewrite your pattern to use less memory if you can. + + One way of reducing the memory usage for such patterns is to make use + of PCRE's "subroutine" facility. Re-writing the above pattern as + + ((ab)(?2){0,999}c)(?1){0,2} + + reduces the memory requirements to 18K, and indeed it remains under 20K + even with the outer repetition increased to 100. However, this pattern + is not exactly equivalent, because the "subroutine" calls are treated + as atomic groups into which there can be no backtracking if there is a + subsequent matching failure. Therefore, PCRE cannot do this kind of + rewriting automatically. Furthermore, there is a noticeable loss of + speed when executing the modified pattern. Nevertheless, if the atomic + grouping is not a problem and the loss of speed is acceptable, this + kind of rewriting will allow you to process patterns that PCRE cannot + otherwise handle. + + +PROCESSING TIME + + Certain items in regular expression patterns are processed more effi- + ciently than others. It is more efficient to use a character class like + [aeiou] than a set of single-character alternatives such as + (a|e|i|o|u). In general, the simplest construction that provides the + required behaviour is usually the most efficient. Jeffrey Friedl's book + contains a lot of useful general discussion about optimizing regular + expressions for efficient performance. This document contains a few + observations about PCRE. Using Unicode character properties (the \p, \P, and \X escapes) is slow, because PCRE has to scan a structure that contains data for over @@ -4423,15 +4715,15 @@ PCRE PERFORMANCE take a long time to run when applied to a string that does not match. Consider the pattern fragment - (a+)* + ^(a+)* - This can match "aaaa" in 33 different ways, and this number increases + This can match "aaaa" in 16 different ways, and this number increases very rapidly as the string gets longer. (The * repeat can match 0, 1, - 2, 3, or 4 times, and for each of those cases other than 0, the + + 2, 3, or 4 times, and for each of those cases other than 0 or 4, the + repeats can match different numbers of times.) When the remainder of the pattern is such that the entire match is going to fail, PCRE has in principle to try every possible variation, and this can take an - extremely long time. + extremely long time, even for relatively short strings. An optimization catches some of the more simple cases such as @@ -4452,8 +4744,8 @@ PCRE PERFORMANCE In many cases, the solution to this kind of performance issue is to use an atomic group or a possessive quantifier. -Last updated: 28 February 2005 -Copyright (c) 1997-2005 University of Cambridge. +Last updated: 20 September 2006 +Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ @@ -4667,7 +4959,7 @@ AUTHOR Philip Hazel University Computing Service, - Cambridge CB2 3QG, England. + Cambridge CB2 3QH, England. Last updated: 16 January 2006 Copyright (c) 1997-2006 University of Cambridge. @@ -4762,11 +5054,34 @@ MATCHING INTERFACE number of sub-patterns, "i"th captured sub-pattern is ignored. + CAVEAT: An optional sub-pattern that does not exist in the matched + string is assigned the empty string. Therefore, the following will + return false (because the empty string is not a valid number): + + int number; + pcrecpp::RE::FullMatch("abc", "[a-z]+(\d+)?", &number); + The matching interface supports at most 16 arguments per call. If you need more, consider using the more general interface pcrecpp::RE::DoMatch. See pcrecpp.h for the signature for DoMatch. +QUOTING METACHARACTERS + + You can use the "QuoteMeta" operation to insert backslashes before all + potentially meaningful characters in a string. The returned string, + used as a regular expression, will exactly match the original string. + + Example: + string quoted = RE::QuoteMeta(unquoted); + + Note that it's legal to escape a character even if it has no special + meaning in a regular expression -- so this function does that. (This + also makes it identical to the perl function of the same name; see + "perldoc -f quotemeta".) For example, "1.5-2.0?" becomes + "1\.5\-2\.0\?". + + PARTIAL MATCHES You can use the "PartialMatch" operation when you want the pattern to @@ -4978,7 +5293,7 @@ REPLACING PARTS OF STRINGS AUTHOR The C++ wrapper was contributed by Google Inc. - Copyright (c) 2005 Google Inc. + Copyright (c) 2006 Google Inc. ------------------------------------------------------------------------------ @@ -5108,21 +5423,25 @@ PCRE DISCUSSION OF STACK USAGE quantifier is used to stop any backtracking into the runs of non-"<" characters, but that is not related to stack usage. + This example shows that one way of avoiding stack problems when match- + ing long subject strings is to write repeated parenthesized subpatterns + to match more than one character whenever possible. + In environments where stack memory is constrained, you might want to compile PCRE to use heap memory instead of stack for remembering back- up points. This makes it run a lot more slowly, however. Details of how to do this are given in the pcrebuild documentation. - In Unix-like environments, there is not often a problem with the stack, - though the default limit on stack size varies from system to system. - Values from 8Mb to 64Mb are common. You can find your default limit by - running the command: + In Unix-like environments, there is not often a problem with the stack + unless very long strings are involved, though the default limit on + stack size varies from system to system. Values from 8Mb to 64Mb are + common. You can find your default limit by running the command: ulimit -s - The effect of running out of stack is often SIGSEGV, though sometimes - an error message is given. You can normally increase the limit on stack - size by code such as this: + Unfortunately, the effect of running out of stack is often SIGSEGV, + though sometimes a more explicit error message is given. You can nor- + mally increase the limit on stack size by code such as this: struct rlimit rlim; getrlimit(RLIMIT_STACK, &rlim); @@ -5144,9 +5463,10 @@ PCRE DISCUSSION OF STACK USAGE recursion. Thus, if you want to limit your stack usage to 8Mb, you should set the limit at 16000 recursions. A 64Mb stack, on the other hand, can support around 128000 recursions. The pcretest test program - has a command line option (-S) that can be used to increase its stack. + has a command line option (-S) that can be used to increase the size of + its stack. -Last updated: 29 June 2006 +Last updated: 14 September 2006 Copyright (c) 1997-2006 University of Cambridge. ------------------------------------------------------------------------------ |