httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pgollu...@apache.org
Subject svn commit: r598343 [7/22] - in /httpd/httpd/vendor/pcre/current: ./ doc/ doc/html/ testdata/
Date Mon, 26 Nov 2007 17:04:37 GMT
Modified: httpd/httpd/vendor/pcre/current/doc/html/pcreapi.html
URL: http://svn.apache.org/viewvc/httpd/httpd/vendor/pcre/current/doc/html/pcreapi.html?rev=598343&r1=598342&r2=598343&view=diff
==============================================================================
--- httpd/httpd/vendor/pcre/current/doc/html/pcreapi.html (original)
+++ httpd/httpd/vendor/pcre/current/doc/html/pcreapi.html Mon Nov 26 09:04:19 2007
@@ -15,26 +15,17 @@
 <ul>
 <li><a name="TOC1" href="#SEC1">PCRE NATIVE API</a>
 <li><a name="TOC2" href="#SEC2">PCRE API OVERVIEW</a>
-<li><a name="TOC3" href="#SEC3">NEWLINES</a>
-<li><a name="TOC4" href="#SEC4">MULTITHREADING</a>
-<li><a name="TOC5" href="#SEC5">SAVING PRECOMPILED PATTERNS FOR LATER USE</a>
-<li><a name="TOC6" href="#SEC6">CHECKING BUILD-TIME OPTIONS</a>
-<li><a name="TOC7" href="#SEC7">COMPILING A PATTERN</a>
-<li><a name="TOC8" href="#SEC8">COMPILATION ERROR CODES</a>
-<li><a name="TOC9" href="#SEC9">STUDYING A PATTERN</a>
-<li><a name="TOC10" href="#SEC10">LOCALE SUPPORT</a>
-<li><a name="TOC11" href="#SEC11">INFORMATION ABOUT A PATTERN</a>
-<li><a name="TOC12" href="#SEC12">OBSOLETE INFO FUNCTION</a>
-<li><a name="TOC13" href="#SEC13">REFERENCE COUNTS</a>
-<li><a name="TOC14" href="#SEC14">MATCHING A PATTERN: THE TRADITIONAL FUNCTION</a>
-<li><a name="TOC15" href="#SEC15">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a>
-<li><a name="TOC16" href="#SEC16">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a>
-<li><a name="TOC17" href="#SEC17">DUPLICATE SUBPATTERN NAMES</a>
-<li><a name="TOC18" href="#SEC18">FINDING ALL POSSIBLE MATCHES</a>
-<li><a name="TOC19" href="#SEC19">MATCHING A PATTERN: THE ALTERNATIVE FUNCTION</a>
-<li><a name="TOC20" href="#SEC20">SEE ALSO</a>
-<li><a name="TOC21" href="#SEC21">AUTHOR</a>
-<li><a name="TOC22" href="#SEC22">REVISION</a>
+<li><a name="TOC3" href="#SEC3">MULTITHREADING</a>
+<li><a name="TOC4" href="#SEC4">SAVING PRECOMPILED PATTERNS FOR LATER USE</a>
+<li><a name="TOC5" href="#SEC5">CHECKING BUILD-TIME OPTIONS</a>
+<li><a name="TOC6" href="#SEC6">COMPILING A PATTERN</a>
+<li><a name="TOC7" href="#SEC7">STUDYING A PATTERN</a>
+<li><a name="TOC8" href="#SEC8">LOCALE SUPPORT</a>
+<li><a name="TOC9" href="#SEC9">INFORMATION ABOUT A PATTERN</a>
+<li><a name="TOC10" href="#SEC10">OBSOLETE INFO FUNCTION</a>
+<li><a name="TOC11" href="#SEC11">MATCHING A PATTERN</a>
+<li><a name="TOC12" href="#SEC12">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a>
+<li><a name="TOC13" href="#SEC13">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a>
 </ul>
 <br><a name="SEC1" href="#TOC1">PCRE NATIVE API</a><br>
 <P>
@@ -46,12 +37,6 @@
 <b>const unsigned char *<i>tableptr</i>);</b>
 </P>
 <P>
-<b>pcre *pcre_compile2(const char *<i>pattern</i>, int <i>options</i>,</b>
-<b>int *<i>errorcodeptr</i>,</b>
-<b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
-<b>const unsigned char *<i>tableptr</i>);</b>
-</P>
-<P>
 <b>pcre_extra *pcre_study(const pcre *<i>code</i>, int <i>options</i>,</b>
 <b>const char **<i>errptr</i>);</b>
 </P>
@@ -61,12 +46,6 @@
 <b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>);</b>
 </P>
 <P>
-<b>int pcre_dfa_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
-<b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
-<b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>,</b>
-<b>int *<i>workspace</i>, int <i>wscount</i>);</b>
-</P>
-<P>
 <b>int pcre_copy_named_substring(const pcre *<i>code</i>,</b>
 <b>const char *<i>subject</i>, int *<i>ovector</i>,</b>
 <b>int <i>stringcount</i>, const char *<i>stringname</i>,</b>
@@ -88,10 +67,6 @@
 <b>const char *<i>name</i>);</b>
 </P>
 <P>
-<b>int pcre_get_stringtable_entries(const pcre *<i>code</i>,</b>
-<b>const char *<i>name</i>, char **<i>first</i>, char **<i>last</i>);</b>
-</P>
-<P>
 <b>int pcre_get_substring(const char *<i>subject</i>, int *<i>ovector</i>,</b>
 <b>int <i>stringcount</i>, int <i>stringnumber</i>,</b>
 <b>const char **<i>stringptr</i>);</b>
@@ -118,9 +93,6 @@
 <b>*<i>firstcharptr</i>);</b>
 </P>
 <P>
-<b>int pcre_refcount(pcre *<i>code</i>, int <i>adjust</i>);</b>
-</P>
-<P>
 <b>int pcre_config(int <i>what</i>, void *<i>where</i>);</b>
 </P>
 <P>
@@ -143,46 +115,32 @@
 </P>
 <br><a name="SEC2" href="#TOC1">PCRE API OVERVIEW</a><br>
 <P>
-PCRE has its own native API, which is described in this document. There are
-also some wrapper functions that correspond to the POSIX regular expression
-API. These are described in the
+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 expression API.
+These are described in the
 <a href="pcreposix.html"><b>pcreposix</b></a>
-documentation. Both of these APIs define a set of C function calls. A C++
-wrapper is distributed with PCRE. It is documented in the
-<a href="pcrecpp.html"><b>pcrecpp</b></a>
-page.
+documentation.
 </P>
 <P>
-The native API C function prototypes are defined in the header file
-<b>pcre.h</b>, and on Unix systems the library itself is called <b>libpcre</b>.
-It can normally be accessed by adding <b>-lpcre</b> to the command for linking
-an application that uses PCRE. The header file defines the macros PCRE_MAJOR
-and PCRE_MINOR to contain the major and minor release numbers for the library.
+The native API function prototypes are defined in the header file <b>pcre.h</b>,
+and on Unix systems the library itself is called <b>libpcre</b>. It can
+normally be accessed by adding <b>-lpcre</b> to the command for linking an
+application that uses PCRE. The header file defines the macros PCRE_MAJOR and
+PCRE_MINOR to contain the major and minor release numbers for the library.
 Applications can use these to include support for different releases of PCRE.
 </P>
 <P>
-The functions <b>pcre_compile()</b>, <b>pcre_compile2()</b>, <b>pcre_study()</b>,
-and <b>pcre_exec()</b> are used for compiling and matching regular expressions
-in a Perl-compatible manner. A sample program that demonstrates the simplest
-way of using them is provided in the file called <i>pcredemo.c</i> in the source
-distribution. The
+The functions <b>pcre_compile()</b>, <b>pcre_study()</b>, and <b>pcre_exec()</b>
+are used for compiling and matching regular expressions. A sample program that
+demonstrates the simplest way of using them is provided in the file called
+<i>pcredemo.c</i> in the source distribution. The
 <a href="pcresample.html"><b>pcresample</b></a>
 documentation describes how to run it.
 </P>
 <P>
-A second matching function, <b>pcre_dfa_exec()</b>, which is not
-Perl-compatible, is also provided. This uses a different algorithm for the
-matching. The alternative algorithm finds all possible matches (at a given
-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
-<a href="pcrematching.html"><b>pcrematching</b></a>
-documentation.
-</P>
-<P>
 In addition to the main compiling and matching functions, there are convenience
-functions for extracting captured substrings from a subject string that is
-matched by <b>pcre_exec()</b>. They are:
+functions for extracting captured substrings from a matched subject string.
+They are:
 <pre>
   <b>pcre_copy_substring()</b>
   <b>pcre_copy_named_substring()</b>
@@ -190,17 +148,16 @@
   <b>pcre_get_named_substring()</b>
   <b>pcre_get_substring_list()</b>
   <b>pcre_get_stringnumber()</b>
-  <b>pcre_get_stringtable_entries()</b>
 </pre>
 <b>pcre_free_substring()</b> and <b>pcre_free_substring_list()</b> are also
 provided, to free the memory used for extracted strings.
 </P>
 <P>
 The function <b>pcre_maketables()</b> is used to build a set of character tables
-in the current locale for passing to <b>pcre_compile()</b>, <b>pcre_exec()</b>,
-or <b>pcre_dfa_exec()</b>. This is an optional facility that is provided for
-specialist use. Most commonly, no special tables are passed, in which case
-internal tables that are generated when PCRE is built are used.
+in the current locale for passing to <b>pcre_compile()</b> or <b>pcre_exec()</b>.
+This is an optional facility that is provided for specialist use. Most
+commonly, no special tables are passed, in which case internal tables that are
+generated when PCRE is built are used.
 </P>
 <P>
 The function <b>pcre_fullinfo()</b> is used to find out information about a
@@ -210,11 +167,6 @@
 version of PCRE and its date of release.
 </P>
 <P>
-The function <b>pcre_refcount()</b> maintains a reference count in a data block
-containing a compiled pattern. This is provided for the benefit of
-object-oriented applications.
-</P>
-<P>
 The global variables <b>pcre_malloc</b> and <b>pcre_free</b> initially contain
 the entry points of the standard <b>malloc()</b> and <b>free()</b> functions,
 respectively. PCRE calls the memory management functions via these variables,
@@ -225,17 +177,12 @@
 The global variables <b>pcre_stack_malloc</b> and <b>pcre_stack_free</b> are also
 indirections to memory management functions. These special functions are used
 only when PCRE is compiled to use the heap for remembering data, instead of
-recursive function calls, when running the <b>pcre_exec()</b> function. See the
-<a href="pcrebuild.html"><b>pcrebuild</b></a>
-documentation for details of how to do this. It is a non-standard way of
-building PCRE, for use in environments that have limited stacks. Because of the
-greater use of memory management, it runs more slowly. Separate functions are
-provided so that special-purpose external code can be used for this case. When
-used, these functions are always called in a stack-like manner (last obtained,
-first freed), and always for memory blocks of the same size. There is a
-discussion about PCRE's stack usage in the
-<a href="pcrestack.html"><b>pcrestack</b></a>
-documentation.
+recursive function calls. This is a non-standard way of building PCRE, for use
+in environments that have limited stacks. Because of the greater use of memory
+management, it runs more slowly. Separate functions are provided so that
+special-purpose external code can be used for this case. When used, these
+functions are always called in a stack-like manner (last obtained, first
+freed), and always for memory blocks of the same size.
 </P>
 <P>
 The global variable <b>pcre_callout</b> initially contains NULL. It can be set
@@ -243,47 +190,8 @@
 points during a matching operation. Details are given in the
 <a href="pcrecallout.html"><b>pcrecallout</b></a>
 documentation.
-<a name="newlines"></a></P>
-<br><a name="SEC3" href="#TOC1">NEWLINES</a><br>
-<P>
-PCRE supports five different conventions for indicating line breaks in
-strings: a single CR (carriage return) character, a single LF (linefeed)
-character, the two-character sequence CRLF, any of the three preceding, or any
-Unicode newline sequence. 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).
-</P>
-<P>
-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 standard. When PCRE is run, the
-default can be overridden, either when a pattern is compiled, or when it is
-matched.
-</P>
-<P>
-At compile time, the newline convention can be specified by the <i>options</i>
-argument of <b>pcre_compile()</b>, or it can be specified by special text at the
-start of the pattern itself; this overrides any other settings. See the
-<a href="pcrepattern.html"><b>pcrepattern</b></a>
-page for details of the special character sequences.
-</P>
-<P>
-In the PCRE documentation the word "newline" is used to mean "the character 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 advancement for a
-non-anchored pattern. There is more detail about this in the
-<a href="#execoptions">section on <b>pcre_exec()</b> options</a>
-below.
-</P>
-<P>
-The choice of newline convention does not affect the interpretation of
-the \n or \r escape sequences, nor does it affect what \R matches, which is
-controlled in a similar way, but by separate options.
 </P>
-<br><a name="SEC4" href="#TOC1">MULTITHREADING</a><br>
+<br><a name="SEC3" href="#TOC1">MULTITHREADING</a><br>
 <P>
 The PCRE functions can be used in multi-threading applications, with the
 proviso that the memory management functions pointed to by <b>pcre_malloc</b>,
@@ -294,17 +202,15 @@
 The compiled form of a regular expression is not altered during matching, so
 the same compiled pattern can safely be used by several threads at once.
 </P>
-<br><a name="SEC5" href="#TOC1">SAVING PRECOMPILED PATTERNS FOR LATER USE</a><br>
+<br><a name="SEC4" href="#TOC1">SAVING PRECOMPILED PATTERNS FOR LATER USE</a><br>
 <P>
 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
 <a href="pcreprecompile.html"><b>pcreprecompile</b></a>
-documentation. However, compiling a regular expression with one version of PCRE
-for use with a different version is not guaranteed to work and may cause
-crashes.
+documentation.
 </P>
-<br><a name="SEC6" href="#TOC1">CHECKING BUILD-TIME OPTIONS</a><br>
+<br><a name="SEC5" href="#TOC1">CHECKING BUILD-TIME OPTIONS</a><br>
 <P>
 <b>int pcre_config(int <i>what</i>, void *<i>where</i>);</b>
 </P>
@@ -331,17 +237,9 @@
 <pre>
   PCRE_CONFIG_NEWLINE
 </pre>
-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, -2 for ANYCRLF, and -1 for ANY. The
-default should normally be the standard sequence for your operating system.
-<pre>
-  PCRE_CONFIG_BSR
-</pre>
-The output is an integer whose value indicates what character sequences the \R
-escape sequence matches by default. A value of 0 means that \R matches any
-Unicode line ending sequence; a value of 1 means that \R matches only CR, LF,
-or CRLF. The default can be overridden when a pattern is compiled or matched.
+The output is an integer that is set to the value of the code that is used for
+the newline character. It is either linefeed (10) or carriage return (13), and
+should normally be the standard character for your operating system.
 <pre>
   PCRE_CONFIG_LINK_SIZE
 </pre>
@@ -365,45 +263,29 @@
 internal matching function calls in a <b>pcre_exec()</b> execution. Further
 details are given with <b>pcre_exec()</b> below.
 <pre>
-  PCRE_CONFIG_MATCH_LIMIT_RECURSION
-</pre>
-The output is an integer that gives the default limit for the depth of
-recursion when calling the internal matching function in a <b>pcre_exec()</b>
-execution. Further details are given with <b>pcre_exec()</b> below.
-<pre>
   PCRE_CONFIG_STACKRECURSE
 </pre>
-The output is an integer that is set to one if internal recursion when running
-<b>pcre_exec()</b> is implemented by recursive function calls that use the stack
-to remember their state. This is the usual way that PCRE is compiled. The
-output is zero if PCRE was compiled to use blocks of data on the heap instead
-of recursive function calls. In this case, <b>pcre_stack_malloc</b> and
-<b>pcre_stack_free</b> are called to manage memory blocks on the heap, thus
-avoiding the use of the stack.
+The output is an integer that is set to one if internal recursion is
+implemented by recursive function calls that use the stack to remember their
+state. This is the usual way that PCRE is compiled. The output is zero if PCRE
+was compiled to use blocks of data on the heap instead of recursive function
+calls. In this case, <b>pcre_stack_malloc</b> and <b>pcre_stack_free</b> are
+called to manage memory blocks on the heap, thus avoiding the use of the stack.
 </P>
-<br><a name="SEC7" href="#TOC1">COMPILING A PATTERN</a><br>
+<br><a name="SEC6" href="#TOC1">COMPILING A PATTERN</a><br>
 <P>
 <b>pcre *pcre_compile(const char *<i>pattern</i>, int <i>options</i>,</b>
 <b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
 <b>const unsigned char *<i>tableptr</i>);</b>
-<b>pcre *pcre_compile2(const char *<i>pattern</i>, int <i>options</i>,</b>
-<b>int *<i>errorcodeptr</i>,</b>
-<b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
-<b>const unsigned char *<i>tableptr</i>);</b>
-</P>
-<P>
-Either of the functions <b>pcre_compile()</b> or <b>pcre_compile2()</b> can be
-called to compile a pattern into an internal form. The only difference between
-the two interfaces is that <b>pcre_compile2()</b> has an additional argument,
-<i>errorcodeptr</i>, via which a numerical error code can be returned.
 </P>
 <P>
-The pattern is a C string terminated by a binary zero, and is passed in the
-<i>pattern</i> argument. A pointer to a single block of memory that is obtained
-via <b>pcre_malloc</b> is returned. This contains the compiled code and related
-data. The <b>pcre</b> type is defined for the returned block; this is a typedef
-for a structure whose contents are not externally defined. It is up to the
-caller to free the memory (via <b>pcre_free</b>) when it is no longer required.
+The function <b>pcre_compile()</b> is called to compile a pattern into an
+internal form. The pattern is a C string terminated by a binary zero, and
+is passed in the <i>pattern</i> argument. A pointer to a single block of memory
+that is obtained via <b>pcre_malloc</b> is returned. This contains the compiled
+code and related data. The <b>pcre</b> type is defined for the returned block;
+this is a typedef for a structure whose contents are not externally defined. It
+is up to the caller to free the memory when it is no longer required.
 </P>
 <P>
 Although the compiled code of a PCRE regex is relocatable, that is, it does not
@@ -412,7 +294,7 @@
 argument, which is an address (see below).
 </P>
 <P>
-The <i>options</i> argument contains various bit settings that affect the
+The <i>options</i> argument contains independent bits that affect the
 compilation. 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
@@ -420,25 +302,18 @@
 <a href="pcrepattern.html"><b>pcrepattern</b></a>
 documentation). For these options, the contents of the <i>options</i> argument
 specifies their initial settings at the start of compilation and execution. The
-PCRE_ANCHORED and PCRE_NEWLINE_<i>xxx</i> options can be set at the time of
-matching as well as at compile time.
+PCRE_ANCHORED option can be set at the time of matching as well as at compile
+time.
 </P>
 <P>
 If <i>errptr</i> is NULL, <b>pcre_compile()</b> returns NULL immediately.
 Otherwise, if compilation of a pattern fails, <b>pcre_compile()</b> returns
 NULL, and sets the variable pointed to by <i>errptr</i> to point to a textual
-error message. This is a static string that is part of the library. You must
-not try to free it. The offset from the start of the pattern to the character
-where the error was discovered is placed in the variable pointed to by
+error message. The offset from the start of the pattern to the character where
+the error was discovered is placed in the variable pointed to by
 <i>erroffset</i>, which must not be NULL. If it is, an immediate error is given.
 </P>
 <P>
-If <b>pcre_compile2()</b> is used instead of <b>pcre_compile()</b>, and the
-<i>errorcodeptr</i> argument is not NULL, a non-zero error code number is
-returned via this argument in the event of an error. This is in addition to the
-textual error message. Error codes and messages are listed below.
-</P>
-<P>
 If the final argument, <i>tableptr</i>, is NULL, PCRE uses a default set of
 character tables that are built when PCRE is compiled, using the default C
 locale. Otherwise, <i>tableptr</i> must be an address that is the result of a
@@ -478,62 +353,39 @@
 <a href="pcrecallout.html"><b>pcrecallout</b></a>
 documentation.
 <pre>
-  PCRE_BSR_ANYCRLF
-  PCRE_BSR_UNICODE
-</pre>
-These options (which are mutually exclusive) control what the \R escape
-sequence matches. The choice is either to match only CR, LF, or CRLF, or to
-match any Unicode newline sequence. The default is specified when PCRE is
-built. It can be overridden from within the pattern, or by setting an option
-when a compiled pattern is matched.
-<pre>
   PCRE_CASELESS
 </pre>
 If this bit is set, letters in the pattern match both upper and lower case
 letters. It is equivalent to Perl's /i option, and it can be changed within a
-pattern by a (?i) option setting. In UTF-8 mode, PCRE always understands the
-concept of case for characters whose values are less than 128, so caseless
-matching is always possible. For characters with higher values, the concept of
-case is supported if PCRE is compiled with Unicode property support, but not
-otherwise. If you want to use caseless matching for characters 128 and above,
-you must ensure that PCRE is compiled with Unicode property support as well as
-with UTF-8 support.
+pattern by a (?i) option setting. When running in UTF-8 mode, case support for
+high-valued characters is available only when PCRE is built with Unicode
+character property support.
 <pre>
   PCRE_DOLLAR_ENDONLY
 </pre>
 If this bit is set, a dollar metacharacter in the pattern matches only at the
 end of the subject string. Without this option, a dollar also matches
-immediately before a newline at the end of the string (but not before any other
-newlines). The PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is set.
-There is no equivalent to this option in Perl, and no way to set it within a
-pattern.
+immediately before the final character if it is a newline (but not before any
+other newlines). The PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is
+set. There is no equivalent to this option in Perl, and no way to set it within
+a pattern.
 <pre>
   PCRE_DOTALL
 </pre>
 If this bit is set, a dot metacharater in the pattern matches all characters,
-including those that indicate newline. Without it, a dot does 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 newline characters, independent of
-the setting of this option.
-<pre>
-  PCRE_DUPNAMES
-</pre>
-If this bit is set, names used to identify capturing subpatterns need not be
-unique. This can be helpful for certain types of pattern when it is known that
-only one instance of the named subpattern can ever be matched. There are more
-details of named subpatterns below; see also the
-<a href="pcrepattern.html"><b>pcrepattern</b></a>
-documentation.
+including newlines. Without it, newlines are excluded. 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 a newline
+character, independent of the setting of this option.
 <pre>
   PCRE_EXTENDED
 </pre>
 If this bit is set, whitespace data characters in the pattern are totally
 ignored except when escaped or inside a character class. Whitespace does not
 include the VT character (code 11). In addition, characters between an
-unescaped # outside a character class and the next newline, inclusive, are also
-ignored. This is equivalent to Perl's /x option, and it can be changed within a
-pattern by a (?x) option setting.
+unescaped # outside a character class and the next newline character,
+inclusive, are also ignored. This is equivalent to Perl's /x option, and it can
+be changed within a pattern by a (?x) option setting.
 </P>
 <P>
 This option makes it possible to include comments inside complicated patterns.
@@ -548,15 +400,9 @@
 set, any backslash in a pattern that is followed by a letter that has no
 special meaning causes an error, thus reserving these combinations for future
 expansion. By default, as in Perl, a backslash followed by a letter with no
-special meaning is treated as a literal. (Perl can, however, be persuaded to
-give a warning for this.) There are at present no other features controlled by
-this option. It can also be set by a (?X) option setting within a pattern.
-<pre>
-  PCRE_FIRSTLINE
-</pre>
-If this option is set, an unanchored pattern is required to match before or at
-the first newline in the subject string, though the matched text may continue
-over the newline.
+special meaning is treated as a literal. There are at present no other features
+controlled by this option. It can also be set by a (?X) option setting within a
+pattern.
 <pre>
   PCRE_MULTILINE
 </pre>
@@ -569,50 +415,12 @@
 </P>
 <P>
 When PCRE_MULTILINE it is set, the "start of line" and "end of line" constructs
-match immediately following or immediately before internal newlines in the
-subject string, respectively, as well as at the very start and end. This is
-equivalent to Perl's /m option, and it can be changed within a pattern by a
-(?m) option setting. If there are no newlines in a subject string, or no
+match immediately following or immediately before any newline in the subject
+string, respectively, as well as at the very start and end. This is equivalent
+to Perl's /m option, and it can be changed within a pattern by a (?m) option
+setting. If there are no "\n" characters in a subject string, or no
 occurrences of ^ or $ in a pattern, setting PCRE_MULTILINE has no effect.
 <pre>
-  PCRE_NEWLINE_CR
-  PCRE_NEWLINE_LF
-  PCRE_NEWLINE_CRLF
-  PCRE_NEWLINE_ANYCRLF
-  PCRE_NEWLINE_ANY
-</pre>
-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
-PCRE_NEWLINE_CRLF specifies that a newline is indicated by the two-character
-CRLF sequence. Setting PCRE_NEWLINE_ANYCRLF specifies that any of the three
-preceding sequences should be recognized. 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.
-</P>
-<P>
-The newline setting in the options word uses three bits that are treated
-as a number, giving eight possibilities. Currently only six are used (default
-plus the five 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 equivalent to PCRE_NEWLINE_CRLF, but
-other combinations may yield unused numbers and cause an error.
-</P>
-<P>
-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.
-</P>
-<P>
-The newline option that is set at compile time becomes the default that is used
-for <b>pcre_exec()</b> and <b>pcre_dfa_exec()</b>, but it can be overridden.
-<pre>
   PCRE_NO_AUTO_CAPTURE
 </pre>
 If this option is set, it disables the use of numbered capturing parentheses in
@@ -642,90 +450,17 @@
   PCRE_NO_UTF8_CHECK
 </pre>
 When PCRE_UTF8 is set, the validity of the pattern as a UTF-8 string is
-automatically checked. There is a discussion about the
-<a href="pcre.html#utf8strings">validity of UTF-8 strings</a>
-in the main
-<a href="pcre.html"><b>pcre</b></a>
-page. If an invalid UTF-8 sequence of bytes is found, <b>pcre_compile()</b>
-returns an error. If you already know that your pattern is valid, and you want
-to skip this check for performance reasons, you can set the PCRE_NO_UTF8_CHECK
-option. When it is set, the effect of passing an invalid UTF-8 string as a
-pattern is undefined. It may cause your program to crash. Note that this option
-can also be passed to <b>pcre_exec()</b> and <b>pcre_dfa_exec()</b>, to suppress
-the UTF-8 validity checking of subject strings.
-</P>
-<br><a name="SEC8" href="#TOC1">COMPILATION ERROR CODES</a><br>
-<P>
-The following table lists the error codes than may be returned by
-<b>pcre_compile2()</b>, along with the error messages that may be returned by
-both compiling functions. As PCRE has developed, some error codes have fallen
-out of use. To avoid confusion, they have not been re-used.
-<pre>
-   0  no error
-   1  \ at end of pattern
-   2  \c at end of pattern
-   3  unrecognized character follows \
-   4  numbers out of order in {} quantifier
-   5  number too big in {} quantifier
-   6  missing terminating ] for character class
-   7  invalid escape sequence in character class
-   8  range out of order in character class
-   9  nothing to repeat
-  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
-  14  missing )
-  15  reference to non-existent subpattern
-  16  erroffset passed as NULL
-  17  unknown option bit(s) set
-  18  missing ) after comment
-  19  [this code is not in use]
-  20  regular expression too large
-  21  failed to get memory
-  22  unmatched parentheses
-  23  internal error: code overflow
-  24  unrecognized character after (?&#60;
-  25  lookbehind assertion is not fixed length
-  26  malformed number or name after (?(
-  27  conditional group contains more than two branches
-  28  assertion expected after (?(
-  29  (?R or (?[+-]digits must be followed by )
-  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  [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
-  37  PCRE does not support \L, \l, \N, \U, or \u
-  38  number after (?C is &#62; 255
-  39  closing ) for (?C expected
-  40  recursive call could loop indefinitely
-  41  unrecognized character 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
-  46  malformed \P or \p sequence
-  47  unknown property name after \P or \p
-  48  subpattern name is too long (maximum 32 characters)
-  49  too many named subpatterns (maximum 10,000)
-  50  [this code is not in use]
-  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
-  57  \g is not followed by a braced name or an optionally braced
-        non-zero number
-  58  (?+ or (?- or (?(+ or (?(- must be followed by a non-zero number
-</PRE>
+automatically checked. If an invalid UTF-8 sequence of bytes is found,
+<b>pcre_compile()</b> returns an error. If you already know that your pattern is
+valid, and you want to skip this check for performance reasons, you can set the
+PCRE_NO_UTF8_CHECK option. When it is set, the effect of passing an invalid
+UTF-8 string as a pattern is undefined. It may cause your program to crash.
+Note that this option can also be passed to <b>pcre_exec()</b>, to suppress the
+UTF-8 validity checking of subject strings.
 </P>
-<br><a name="SEC9" href="#TOC1">STUDYING A PATTERN</a><br>
+<br><a name="SEC7" href="#TOC1">STUDYING A PATTERN</a><br>
 <P>
-<b>pcre_extra *pcre_study(const pcre *<i>code</i>, int <i>options</i></b>
+<b>pcre_extra *pcre_study(const pcre *<i>code</i>, int <i>options</i>,</b>
 <b>const char **<i>errptr</i>);</b>
 </P>
 <P>
@@ -746,7 +481,7 @@
 in the section on matching a pattern.
 </P>
 <P>
-If studying the pattern does not produce any additional information
+If studying the pattern does not produce any additional information,
 <b>pcre_study()</b> returns NULL. In that circumstance, if the calling program
 wants to pass any of the other fields to <b>pcre_exec()</b>, it must set up its
 own <b>pcre_extra</b> block.
@@ -758,10 +493,9 @@
 <P>
 The third argument for <b>pcre_study()</b> is a pointer for an error message. If
 studying succeeds (even if no data is returned), the variable it points to is
-set to NULL. Otherwise it is set to point to a textual error message. This is a
-static string that is part of the library. You must not try to free it. You
-should test the error pointer for NULL after calling <b>pcre_study()</b>, to be
-sure that it has run successfully.
+set to NULL. Otherwise it points to a textual error message. You should
+therefore test the error pointer for NULL after calling <b>pcre_study()</b>, to
+be sure that it has run successfully.
 </P>
 <P>
 This is a typical call to <b>pcre_study</b>():
@@ -776,29 +510,22 @@
 not have a single fixed starting character. A bitmap of possible starting
 bytes is created.
 <a name="localesupport"></a></P>
-<br><a name="SEC10" href="#TOC1">LOCALE SUPPORT</a><br>
+<br><a name="SEC8" href="#TOC1">LOCALE SUPPORT</a><br>
 <P>
 PCRE handles caseless matching, and determines whether characters are letters,
 digits, or whatever, by reference to a set of tables, indexed by character
-value. When running in UTF-8 mode, this applies only to characters with codes
+value. (When running in UTF-8 mode, this applies only to characters with codes
 less than 128. Higher-valued codes never match escapes such as \w or \d, but
 can be tested with \p if PCRE is built with Unicode character property
-support. The use of locales with Unicode is discouraged. If you are handling
-characters with codes greater than 128, you should either use UTF-8 and
-Unicode, or use locales, but not try to mix the two.
-</P>
-<P>
-PCRE contains an internal set of tables that are used when the final argument
-of <b>pcre_compile()</b> is NULL. These are sufficient for many applications.
-Normally, the internal tables recognize only ASCII characters. However, when
-PCRE is built, it is possible to cause the internal tables to be rebuilt in the
-default "C" locale of the local system, which may cause them to be different.
-</P>
-<P>
-The internal tables can always be overridden by tables supplied by the
-application that calls PCRE. These may be created in a different locale from
-the default. As more and more applications change to using Unicode, the need
-for this locale support is expected to die away.
+support.)
+</P>
+<P>
+An internal set of tables is created in the default C locale when PCRE is
+built. This is used when the final argument of <b>pcre_compile()</b> is NULL,
+and is sufficient for many applications. An alternative set of tables can,
+however, be supplied. These may be created in a different locale from the
+default. As more and more applications change to using Unicode, the need for
+this locale support is expected to die away.
 </P>
 <P>
 External tables are built by calling the <b>pcre_maketables()</b> function,
@@ -812,10 +539,6 @@
   tables = pcre_maketables();
   re = pcre_compile(..., tables);
 </pre>
-The locale name "fr_FR" is used on Linux and other Unix-like systems; if you
-are using Windows, the name for the French locale is "french".
-</P>
-<P>
 When <b>pcre_maketables()</b> runs, the tables are built in memory that is
 obtained via <b>pcre_malloc</b>. It is the caller's responsibility to ensure
 that the memory containing the tables remains available for as long as it is
@@ -835,7 +558,7 @@
 one in which it was compiled. Passing table pointers at run time is discussed
 below in the section on matching a pattern.
 </P>
-<br><a name="SEC11" href="#TOC1">INFORMATION ABOUT A PATTERN</a><br>
+<br><a name="SEC9" href="#TOC1">INFORMATION ABOUT A PATTERN</a><br>
 <P>
 <b>int pcre_fullinfo(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
 <b>int <i>what</i>, void *<i>where</i>);</b>
@@ -863,7 +586,7 @@
 <b>pcre_fullinfo()</b>, to obtain the length of the compiled pattern:
 <pre>
   int rc;
-  size_t length;
+  unsigned long int length;
   rc = pcre_fullinfo(
     re,               /* result of pcre_compile() */
     pe,               /* result of pcre_study(), or NULL */
@@ -884,7 +607,7 @@
 Return the number of capturing subpatterns in the pattern. The fourth argument
 should point to an <b>int</b> variable.
 <pre>
-  PCRE_INFO_DEFAULT_TABLES
+  PCRE_INFO_DEFAULTTABLES
 </pre>
 Return a pointer to the internal default character tables within PCRE. The
 fourth argument should point to an <b>unsigned char *</b> variable. This
@@ -895,13 +618,13 @@
   PCRE_INFO_FIRSTBYTE
 </pre>
 Return information about the first byte of any matched string, for a
-non-anchored pattern. The fourth argument should point to an <b>int</b>
-variable. (This option used to be called PCRE_INFO_FIRSTCHAR; the old name is
-still recognized for backwards compatibility.)
+non-anchored pattern. (This option used to be called PCRE_INFO_FIRSTCHAR; the
+old name is still recognized for backwards compatibility.)
 </P>
 <P>
 If there is a fixed first byte, for example, from a pattern such as
-(cat|cow|coyote), its value is returned. Otherwise, if either
+(cat|cow|coyote), it is returned in the integer pointed to by <i>where</i>.
+Otherwise, if either
 <br>
 <br>
 (a) the pattern was compiled with the PCRE_MULTILINE option, and every branch
@@ -923,18 +646,6 @@
 string, a pointer to the table is returned. Otherwise NULL is returned. The
 fourth argument should point to an <b>unsigned char *</b> variable.
 <pre>
-  PCRE_INFO_HASCRORLF
-</pre>
-Return 1 if the pattern contains any explicit matches for CR or LF characters,
-otherwise 0. The fourth argument should point to an <b>int</b> variable. An
-explicit match is either a literal CR or LF character, or \r or \n.
-<pre>
-  PCRE_INFO_JCHANGED
-</pre>
-Return 1 if the (?J) option setting is used in the pattern, otherwise 0. The
-fourth argument should point to an <b>int</b> variable. The (?J) internal option
-setting changes the local PCRE_DUPNAMES option.
-<pre>
   PCRE_INFO_LASTLITERAL
 </pre>
 Return the value of the rightmost literal byte that must exist in any matched
@@ -951,13 +662,12 @@
 </pre>
 PCRE supports the use of named as well as numbered capturing parentheses. The
 names are just an additional way of identifying the parentheses, which still
-acquire numbers. Several convenience functions such as
-<b>pcre_get_named_substring()</b> are provided for extracting captured
-substrings by name. It is also possible to extract the data directly, by first
-converting the name to a number in order to access the correct pointers in the
-output vector (described with <b>pcre_exec()</b> below). To do the conversion,
-you need to use the name-to-number map, which is described by these three
-values.
+acquire numbers. A convenience function called <b>pcre_get_named_substring()</b>
+is provided for extracting an individual captured substring by name. It is also
+possible to extract the data directly, by first converting the name to a number
+in order to access the correct pointers in the output vector (described with
+<b>pcre_exec()</b> below). To do the conversion, you need to use the
+name-to-number map, which is described by these three values.
 </P>
 <P>
 The map consists of a number of fixed-size entries. PCRE_INFO_NAMECOUNT gives
@@ -967,11 +677,10 @@
 entry of the table (a pointer to <b>char</b>). The first two bytes of each entry
 are the number of the capturing parenthesis, most significant byte first. The
 rest of the entry is the corresponding name, zero terminated. The names are in
-alphabetical order. When PCRE_DUPNAMES is set, duplicate names are in order of
-their parentheses numbers. For example, consider the following pattern (assume
+alphabetical order. For example, consider the following pattern (assume
 PCRE_EXTENDED is set, so white space - including newlines - is ignored):
 <pre>
-  (?&#60;date&#62; (?&#60;year&#62;(\d\d)?\d\d) - (?&#60;month&#62;\d\d) - (?&#60;day&#62;\d\d) )
+  (?P&#60;date&#62; (?P&#60;year&#62;(\d\d)?\d\d) - (?P&#60;month&#62;\d\d) - (?P&#60;day&#62;\d\d) )
 </pre>
 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, with non-printing
@@ -983,26 +692,15 @@
   00 02 y  e  a  r  00 ??
 </pre>
 When writing code to extract data from named subpatterns using the
-name-to-number map, remember that the length of the entries is likely to be
+name-to-number map, remember that the length of each entry is likely to be
 different for each compiled pattern.
 <pre>
-  PCRE_INFO_OKPARTIAL
-</pre>
-Return 1 if the pattern can be used for partial matching, otherwise 0. The
-fourth argument should point to an <b>int</b> variable. The
-<a href="pcrepartial.html"><b>pcrepartial</b></a>
-documentation lists the restrictions that apply to patterns when partial
-matching is used.
-<pre>
   PCRE_INFO_OPTIONS
 </pre>
 Return a copy of the options with which the pattern was compiled. The fourth
 argument should point to an <b>unsigned long int</b> variable. These option bits
 are those specified in the call to <b>pcre_compile()</b>, modified by any
-top-level option settings at the start of the pattern itself. In other words,
-they are the options that will be in force when matching starts. For example,
-if the pattern /(?im)abc(?-i)d/ is compiled with the PCRE_EXTENDED option, the
-result is PCRE_CASELESS, PCRE_MULTILINE, and PCRE_EXTENDED.
+top-level option settings within the pattern itself.
 </P>
 <P>
 A pattern is automatically anchored by PCRE if all of its top-level
@@ -1031,7 +729,7 @@
 created by <b>pcre_study()</b>. The fourth argument should point to a
 <b>size_t</b> variable.
 </P>
-<br><a name="SEC12" href="#TOC1">OBSOLETE INFO FUNCTION</a><br>
+<br><a name="SEC10" href="#TOC1">OBSOLETE INFO FUNCTION</a><br>
 <P>
 <b>int pcre_info(const pcre *<i>code</i>, int *<i>optptr</i>, int</b>
 <b>*<i>firstcharptr</i>);</b>
@@ -1055,31 +753,7 @@
 it is used to pass back information about the first character of any matched
 string (see PCRE_INFO_FIRSTBYTE above).
 </P>
-<br><a name="SEC13" href="#TOC1">REFERENCE COUNTS</a><br>
-<P>
-<b>int pcre_refcount(pcre *<i>code</i>, int <i>adjust</i>);</b>
-</P>
-<P>
-The <b>pcre_refcount()</b> function is used to maintain a reference count in the
-data block that contains a compiled pattern. It is provided for the benefit of
-applications that operate in an object-oriented manner, where different parts
-of the application may be using the same compiled pattern, but you want to free
-the block when they are all done.
-</P>
-<P>
-When a pattern is compiled, the reference count field is initialized to zero.
-It is changed only by calling this function, whose action is to add the
-<i>adjust</i> value (which may be positive or negative) to it. The yield of the
-function is the new value. However, the value of the count is constrained to
-lie between 0 and 65535, inclusive. If the new value is outside these limits,
-it is forced to the appropriate limit value.
-</P>
-<P>
-Except when it is zero, the reference count is not correctly preserved if a
-pattern is compiled on one host and then transferred to a host whose byte-order
-is different. (This seems a highly unlikely scenario.)
-</P>
-<br><a name="SEC14" href="#TOC1">MATCHING A PATTERN: THE TRADITIONAL FUNCTION</a><br>
+<br><a name="SEC11" href="#TOC1">MATCHING A PATTERN</a><br>
 <P>
 <b>int pcre_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
 <b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
@@ -1089,11 +763,7 @@
 The function <b>pcre_exec()</b> is called to match a subject string against a
 compiled pattern, which is passed in the <i>code</i> argument. If the
 pattern has been studied, the result of the study should be passed in the
-<i>extra</i> argument. This function is the main matching facility of the
-library, and it operates in a Perl-like manner. For specialist use there is
-also an alternative matching function, which is described
-<a href="#dfamatch">below</a>
-in the section about the <b>pcre_dfa_exec()</b> function.
+<i>extra</i> argument.
 </P>
 <P>
 In most applications, the pattern will have been compiled (and optionally
@@ -1117,7 +787,7 @@
     0,              /* start at offset 0 in the subject */
     0,              /* default options */
     ovector,        /* vector of integers for substring information */
-    30);            /* number of elements (NOT size in bytes) */
+    30);            /* number of elements in the vector (NOT size in bytes) */
 <a name="extradata"></a></PRE>
 </P>
 <br><b>
@@ -1127,13 +797,12 @@
 If the <i>extra</i> argument is not NULL, it must point to a <b>pcre_extra</b>
 data block. The <b>pcre_study()</b> function returns such a block (when it
 doesn't return NULL), but you can also create one for yourself, and pass
-additional information in it. The <b>pcre_extra</b> block contains the following
-fields (not necessarily in this order):
+additional information in it. The fields in a <b>pcre_extra</b> block are as
+follows:
 <pre>
   unsigned long int <i>flags</i>;
   void *<i>study_data</i>;
   unsigned long int <i>match_limit</i>;
-  unsigned long int <i>match_limit_recursion</i>;
   void *<i>callout_data</i>;
   const unsigned char *<i>tables</i>;
 </pre>
@@ -1142,7 +811,6 @@
 <pre>
   PCRE_EXTRA_STUDY_DATA
   PCRE_EXTRA_MATCH_LIMIT
-  PCRE_EXTRA_MATCH_LIMIT_RECURSION
   PCRE_EXTRA_CALLOUT_DATA
   PCRE_EXTRA_TABLES
 </pre>
@@ -1159,39 +827,18 @@
 </P>
 <P>
 Internally, PCRE uses a function called <b>match()</b> which it calls repeatedly
-(sometimes recursively). The limit set by <i>match_limit</i> is imposed on the
-number of times this function is called during a match, which has the effect of
-limiting the amount of backtracking that can take place. For patterns that are
-not anchored, the count restarts from zero for each position in the subject
-string.
+(sometimes recursively). The limit is imposed on the number of times this
+function is called during a match, which has the effect of limiting the amount
+of recursion and backtracking that can take place. For patterns that are not
+anchored, the count starts from zero for each position in the subject string.
 </P>
 <P>
-The default value for the limit can be set when PCRE is built; the default
+The default limit for the library can be set when PCRE is built; the default
 default is 10 million, which handles all but the most extreme cases. You can
-override the default by suppling <b>pcre_exec()</b> with a <b>pcre_extra</b>
-block in which <i>match_limit</i> is set, and PCRE_EXTRA_MATCH_LIMIT is set in
-the <i>flags</i> field. If the limit is exceeded, <b>pcre_exec()</b> returns
-PCRE_ERROR_MATCHLIMIT.
-</P>
-<P>
-The <i>match_limit_recursion</i> field is similar to <i>match_limit</i>, but
-instead of limiting the total number of times that <b>match()</b> is called, it
-limits the depth of recursion. The recursion depth is a smaller number than the
-total number of calls, because not all calls to <b>match()</b> are recursive.
-This limit is of use only if it is set smaller than <i>match_limit</i>.
-</P>
-<P>
-Limiting the recursion depth limits the amount of stack that can be used, or,
-when PCRE has been compiled to use memory on the heap instead of the stack, the
-amount of heap memory that can be used.
-</P>
-<P>
-The default value for <i>match_limit_recursion</i> can be set when PCRE is
-built; the default default is the same value as the default for
-<i>match_limit</i>. You can override the default by suppling <b>pcre_exec()</b>
-with a <b>pcre_extra</b> block in which <i>match_limit_recursion</i> is set, and
-PCRE_EXTRA_MATCH_LIMIT_RECURSION is set in the <i>flags</i> field. If the limit
-is exceeded, <b>pcre_exec()</b> returns PCRE_ERROR_RECURSIONLIMIT.
+reduce the default by suppling <b>pcre_exec()</b> with a <b>pcre_extra</b> block
+in which <i>match_limit</i> is set to a smaller value, and
+PCRE_EXTRA_MATCH_LIMIT is set in the <i>flags</i> field. If the limit is
+exceeded, <b>pcre_exec()</b> returns PCRE_ERROR_MATCHLIMIT.
 </P>
 <P>
 The <i>pcre_callout</i> field is used in conjunction with the "callout" feature,
@@ -1211,14 +858,14 @@
 called. See the
 <a href="pcreprecompile.html"><b>pcreprecompile</b></a>
 documentation for a discussion of saving compiled patterns for later use.
-<a name="execoptions"></a></P>
+</P>
 <br><b>
 Option bits for <b>pcre_exec()</b>
 </b><br>
 <P>
 The unused bits of the <i>options</i> argument for <b>pcre_exec()</b> must be
-zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NEWLINE_<i>xxx</i>,
-PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, PCRE_NO_UTF8_CHECK and PCRE_PARTIAL.
+zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NOTBOL,
+PCRE_NOTEOL, PCRE_NOTEMPTY, PCRE_NO_UTF8_CHECK and PCRE_PARTIAL.
 <pre>
   PCRE_ANCHORED
 </pre>
@@ -1227,52 +874,6 @@
 to be anchored by virtue of its contents, it cannot be made unachored at
 matching time.
 <pre>
-  PCRE_BSR_ANYCRLF
-  PCRE_BSR_UNICODE
-</pre>
-These options (which are mutually exclusive) control what the \R escape
-sequence matches. The choice is either to match only CR, LF, or CRLF, or to
-match any Unicode newline sequence. These options override the choice that was
-made or defaulted when the pattern was compiled.
-<pre>
-  PCRE_NEWLINE_CR
-  PCRE_NEWLINE_LF
-  PCRE_NEWLINE_CRLF
-  PCRE_NEWLINE_ANYCRLF
-  PCRE_NEWLINE_ANY
-</pre>
-These options override the newline definition that was chosen or defaulted when
-the pattern was compiled. For details, see the description of
-<b>pcre_compile()</b> above. During matching, the newline choice affects the
-behaviour of the dot, circumflex, and dollar metacharacters. It may also alter
-the way the match position is advanced after a match failure for an unanchored
-pattern.
-</P>
-<P>
-When PCRE_NEWLINE_CRLF, PCRE_NEWLINE_ANYCRLF, or PCRE_NEWLINE_ANY is set, and a
-match attempt for an unanchored pattern fails when the current position is at a
-CRLF sequence, and the pattern contains no explicit matches for CR or LF
-characters, the match position is advanced by two characters instead of one, in
-other words, to after the CRLF.
-</P>
-<P>
-The above rule is a compromise that makes the most common cases work as
-expected. For example, if the pattern is .+A (and the PCRE_DOTALL option is not
-set), it does not match the string "\r\nA" because, after failing at the
-start, it skips both the CR and the LF before retrying. However, the pattern
-[\r\n]A does match that string, because it contains an explicit CR or LF
-reference, and so advances only by one character after the first failure.
-</P>
-<P>
-An explicit match for CR of LF is either a literal appearance of one of those
-characters, or one of the \r or \n escape sequences. Implicit matches such as
-[^X] do not count, nor does \s (which includes CR and LF in the characters
-that it matches).
-</P>
-<P>
-Notwithstanding the above, anomalous effects may still occur when CRLF is a
-valid newline sequence and explicit \r or \n escapes appear in the pattern.
-<pre>
   PCRE_NOTBOL
 </pre>
 This option specifies that first character of the subject string is not the
@@ -1315,14 +916,9 @@
 When PCRE_UTF8 is set at compile time, the validity of the subject as a UTF-8
 string is automatically checked when <b>pcre_exec()</b> is subsequently called.
 The value of <i>startoffset</i> is also checked to ensure that it points to the
-start of a UTF-8 character. There is a discussion about the validity of UTF-8
-strings in the
-<a href="pcre.html#utf8strings">section on UTF-8 support</a>
-in the main
-<a href="pcre.html"><b>pcre</b></a>
-page. If an invalid UTF-8 sequence of bytes is found, <b>pcre_exec()</b> returns
-the error PCRE_ERROR_BADUTF8. If <i>startoffset</i> contains an invalid value,
-PCRE_ERROR_BADUTF8_OFFSET is returned.
+start of a UTF-8 character. If an invalid UTF-8 sequence of bytes is found,
+<b>pcre_exec()</b> returns the error PCRE_ERROR_BADUTF8. If <i>startoffset</i>
+contains an invalid value, PCRE_ERROR_BADUTF8_OFFSET is returned.
 </P>
 <P>
 If you already know that your subject is valid, and you want to skip these
@@ -1416,10 +1012,20 @@
 first pair, <i>ovector[0]</i> and <i>ovector[1]</i>, identify the portion of the
 subject string matched by the entire pattern. The next pair is used for the
 first capturing subpattern, and so on. The value returned by <b>pcre_exec()</b>
-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 that just the first pair of offsets has been set.
+is the number of pairs that have been set. 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.
+</P>
+<P>
+Some convenience functions are provided for extracting the captured substrings
+as separate strings. These are described in the following section.
+</P>
+<P>
+It is possible for an capturing subpattern number <i>n+1</i> to match some
+part of the subject when subpattern <i>n</i> has not been used at all. For
+example, if the string "abc" is matched against the pattern (a|(z))(bc)
+subpatterns 1 and 3 are matched, but 2 is not. When this happens, both offset
+values corresponding to the unused subpattern are set to -1.
 </P>
 <P>
 If a capturing subpattern is matched repeatedly, it is the last portion of the
@@ -1436,34 +1042,13 @@
 advisable to supply an <i>ovector</i>.
 </P>
 <P>
-The <b>pcre_info()</b> function can be used to find out how many capturing
+Note that <b>pcre_info()</b> can be used to find out how many capturing
 subpatterns there are in a compiled pattern. The smallest size for
 <i>ovector</i> that will allow for <i>n</i> captured substrings, in addition to
 the offsets of the substring matched by the whole pattern, is (<i>n</i>+1)*3.
 </P>
-<P>
-It is possible for capturing subpattern number <i>n+1</i> to match some part of
-the subject when subpattern <i>n</i> has not been used at all. For example, 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 corresponding to unused subpatterns
-are set to -1.
-</P>
-<P>
-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 the vector is large enough, of
-course).
-</P>
-<P>
-Some convenience functions are provided for extracting the captured substrings
-as separate strings. These are described below.
-<a name="errorlist"></a></P>
 <br><b>
-Error return values from <b>pcre_exec()</b>
+Return values from <b>pcre_exec()</b>
 </b><br>
 <P>
 If <b>pcre_exec()</b> fails, it returns a negative number. The following are
@@ -1490,7 +1075,7 @@
 other endianness. This is the error that PCRE gives when the magic number is
 not present.
 <pre>
-  PCRE_ERROR_UNKNOWN_OPCODE (-5)
+  PCRE_ERROR_UNKNOWN_NODE   (-5)
 </pre>
 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 overwriting
@@ -1512,9 +1097,9 @@
 <pre>
   PCRE_ERROR_MATCHLIMIT     (-8)
 </pre>
-The backtracking limit, as specified by the <i>match_limit</i> field in a
-<b>pcre_extra</b> structure (or defaulted) was reached. See the description
-above.
+The recursion and backtracking limit, as specified by the <i>match_limit</i>
+field in a <b>pcre_extra</b> structure (or defaulted) was reached. See the
+description above.
 <pre>
   PCRE_ERROR_CALLOUT        (-9)
 </pre>
@@ -1532,42 +1117,29 @@
 The UTF-8 byte sequence that was passed as a subject was valid, but the value
 of <i>startoffset</i> did not point to the beginning of a UTF-8 character.
 <pre>
-  PCRE_ERROR_PARTIAL        (-12)
+  PCRE_ERROR_PARTIAL (-12)
 </pre>
 The subject string did not match, but it did match partially. See the
 <a href="pcrepartial.html"><b>pcrepartial</b></a>
 documentation for details of partial matching.
 <pre>
-  PCRE_ERROR_BADPARTIAL     (-13)
+  PCRE_ERROR_BAD_PARTIAL (-13)
 </pre>
 The PCRE_PARTIAL option was used with a compiled pattern containing items that
 are not supported for partial matching. See the
 <a href="pcrepartial.html"><b>pcrepartial</b></a>
 documentation for details of partial matching.
 <pre>
-  PCRE_ERROR_INTERNAL       (-14)
+  PCRE_ERROR_INTERNAL (-14)
 </pre>
 An unexpected internal error has occurred. This error could be caused by a bug
 in PCRE or by overwriting of the compiled pattern.
 <pre>
-  PCRE_ERROR_BADCOUNT       (-15)
+  PCRE_ERROR_BADCOUNT (-15)
 </pre>
 This error is given if the value of the <i>ovecsize</i> argument is negative.
-<pre>
-  PCRE_ERROR_RECURSIONLIMIT (-21)
-</pre>
-The internal recursion limit, as specified by the <i>match_limit_recursion</i>
-field in a <b>pcre_extra</b> structure (or defaulted) was reached. See the
-description above.
-<pre>
-  PCRE_ERROR_BADNEWLINE     (-23)
-</pre>
-An invalid combination of PCRE_NEWLINE_<i>xxx</i> options was given.
-</P>
-<P>
-Error numbers -16 to -20 and -22 are not used by <b>pcre_exec()</b>.
 </P>
-<br><a name="SEC15" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a><br>
+<br><a name="SEC12" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a><br>
 <P>
 <b>int pcre_copy_substring(const char *<i>subject</i>, int *<i>ovector</i>,</b>
 <b>int <i>stringcount</i>, int <i>stringnumber</i>, char *<i>buffer</i>,</b>
@@ -1589,16 +1161,9 @@
 <b>pcre_get_substring_list()</b> 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.
-</P>
-<P>
-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 <b>pcre_copy_substring()</b> and <b>pcre_get_substring()</b>.
-Unfortunately, the interface to <b>pcre_get_substring_list()</b> is not adequate
-for handling strings containing binary zeros, because the end of the final
-string is not independently indicated.
+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.
 </P>
 <P>
 The first three arguments are the same for all three of these functions:
@@ -1620,7 +1185,7 @@
 <i>buffersize</i>, while for <b>pcre_get_substring()</b> a new block of memory is
 obtained via <b>pcre_malloc</b>, and its address is returned via
 <i>stringptr</i>. The yield of the function is the length of the string, not
-including the terminating zero, or one of these error codes:
+including the terminating zero, or one of
 <pre>
   PCRE_ERROR_NOMEMORY       (-6)
 </pre>
@@ -1637,7 +1202,7 @@
 memory that is obtained via <b>pcre_malloc</b>. The address of the memory block
 is returned via <i>listptr</i>, 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
+function is zero if all went well, or
 <pre>
   PCRE_ERROR_NOMEMORY       (-6)
 </pre>
@@ -1658,11 +1223,11 @@
 <b>pcre_get_substring_list()</b>, respectively. They do nothing more than call
 the function pointed to by <b>pcre_free</b>, which of course could be called
 directly from a C program. However, PCRE is used in some situations where it is
-linked via a special interface to another programming language that cannot use
+linked via a special interface to another programming language which cannot use
 <b>pcre_free</b> directly; it is for these cases that the functions are
 provided.
 </P>
-<br><a name="SEC16" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a><br>
+<br><a name="SEC13" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a><br>
 <P>
 <b>int pcre_get_stringnumber(const pcre *<i>code</i>,</b>
 <b>const char *<i>name</i>);</b>
@@ -1685,10 +1250,9 @@
 <pre>
   (a+)b(?&#60;xxx&#62;\d+)...
 </pre>
-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 name by
-calling <b>pcre_get_stringnumber()</b>. The first argument is the compiled
-pattern, and the second is the name. The yield of the function is the
+the number of the subpattern called "xxx" is 2. You can find the number from
+the name by calling <b>pcre_get_stringnumber()</b>. The first argument is the
+compiled pattern, and the second is the name. The yield of the function is the
 subpattern number, or PCRE_ERROR_NOSUBSTRING (-7) if there is no subpattern of
 that name.
 </P>
@@ -1698,8 +1262,8 @@
 two functions that do the whole job.
 </P>
 <P>
-Most of the arguments of <b>pcre_copy_named_substring()</b> and
-<b>pcre_get_named_substring()</b> are the same as those for the similarly named
+Most of the arguments of <i>pcre_copy_named_substring()</i> and
+<i>pcre_get_named_substring()</i> are the same as those for the similarly named
 functions that extract by number. As these are described in the previous
 section, they are not re-described here. There are just two differences:
 </P>
@@ -1711,247 +1275,13 @@
 </P>
 <P>
 These functions call <b>pcre_get_stringnumber()</b>, and if it succeeds, they
-then call <b>pcre_copy_substring()</b> or <b>pcre_get_substring()</b>, as
-appropriate. <b>NOTE:</b> If PCRE_DUPNAMES is set and there are duplicate names,
-the behaviour may not be what you want (see the next section).
-</P>
-<br><a name="SEC17" href="#TOC1">DUPLICATE SUBPATTERN NAMES</a><br>
-<P>
-<b>int pcre_get_stringtable_entries(const pcre *<i>code</i>,</b>
-<b>const char *<i>name</i>, char **<i>first</i>, char **<i>last</i>);</b>
-</P>
-<P>
-When a pattern is compiled with the PCRE_DUPNAMES option, names for subpatterns
-are not required to be unique. Normally, patterns with duplicate names are such
-that in any one match, only one of the named subpatterns participates. An
-example is shown in the
-<a href="pcrepattern.html"><b>pcrepattern</b></a>
-documentation.
-</P>
-<P>
-When duplicates are present, <b>pcre_copy_named_substring()</b> and
-<b>pcre_get_named_substring()</b> return the first substring corresponding to
-the given name that is set. If none are set, PCRE_ERROR_NOSUBSTRING (-7) is
-returned; no data is returned. The <b>pcre_get_stringnumber()</b> function
-returns one of the numbers that are associated with the name, but it is not
-defined which it is.
-</P>
-<P>
-If you want to get full details of all captured substrings for a given name,
-you must use the <b>pcre_get_stringtable_entries()</b> function. The first
-argument is the compiled pattern, and the second is the name. The 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 (-7) if there are none. The format of the table is
-described above in the section entitled <i>Information about a pattern</i>.
-Given all the relevant entries for the name, you can extract each of their
-numbers, and hence the captured data, if any.
-</P>
-<br><a name="SEC18" href="#TOC1">FINDING ALL POSSIBLE MATCHES</a><br>
-<P>
-The traditional matching function uses a similar algorithm to Perl, which stops
-when it finds the first match, starting at a given point in the subject. If you
-want to find all possible matches, or the longest possible match, consider
-using the alternative matching function (see below) instead. If you cannot use
-the alternative function, but still need to find all possible matches, you
-can kludge it up by making use of the callout facility, which is described in
-the
-<a href="pcrecallout.html"><b>pcrecallout</b></a>
-documentation.
-</P>
-<P>
-What you have to do is to insert a callout right at the end of the pattern.
-When your callout function is called, extract and save the current matched
-substring. Then return 1, which forces <b>pcre_exec()</b> to backtrack and try
-other alternatives. Ultimately, when it runs out of matches, <b>pcre_exec()</b>
-will yield PCRE_ERROR_NOMATCH.
-<a name="dfamatch"></a></P>
-<br><a name="SEC19" href="#TOC1">MATCHING A PATTERN: THE ALTERNATIVE FUNCTION</a><br>
-<P>
-<b>int pcre_dfa_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
-<b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
-<b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>,</b>
-<b>int *<i>workspace</i>, int <i>wscount</i>);</b>
-</P>
-<P>
-The function <b>pcre_dfa_exec()</b> is called to match a subject string 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. Nevertheless, there are times when this kind of
-matching can be useful. For a discussion of the two matching algorithms, see
-the
-<a href="pcrematching.html"><b>pcrematching</b></a>
-documentation.
+then call <i>pcre_copy_substring()</i> or <i>pcre_get_substring()</i>, as
+appropriate.
 </P>
 <P>
-The arguments for the <b>pcre_dfa_exec()</b> function are the same as for
-<b>pcre_exec()</b>, plus two extras. The <i>ovector</i> argument is used in a
-different way, and this is described below. The other common arguments are used
-in the same way as for <b>pcre_exec()</b>, so their description is not repeated
-here.
-</P>
-<P>
-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 lot of potential matches.
-</P>
-<P>
-Here is an example of a simple call to <b>pcre_dfa_exec()</b>:
-<pre>
-  int rc;
-  int ovector[10];
-  int wspace[20];
-  rc = pcre_dfa_exec(
-    re,             /* result of pcre_compile() */
-    NULL,           /* we didn't study the pattern */
-    "some string",  /* the subject string */
-    11,             /* the length of the subject string */
-    0,              /* start at offset 0 in the subject */
-    0,              /* default options */
-    ovector,        /* vector of integers for substring information */
-    10,             /* number of elements (NOT size in bytes) */
-    wspace,         /* working space vector */
-    20);            /* number of elements (NOT size in bytes) */
-</PRE>
-</P>
-<br><b>
-Option bits for <b>pcre_dfa_exec()</b>
-</b><br>
-<P>
-The unused bits of the <i>options</i> argument for <b>pcre_dfa_exec()</b> must be
-zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NEWLINE_<i>xxx</i>,
-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 <b>pcre_exec()</b>, so their description is not repeated here.
-<pre>
-  PCRE_PARTIAL
-</pre>
-This has the same general effect as it does for <b>pcre_exec()</b>, but the
-details are slightly different. When PCRE_PARTIAL is set for
-<b>pcre_dfa_exec()</b>, 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 possibility. The
-portion of the string that provided the partial match is set as the first
-matching string.
-<pre>
-  PCRE_DFA_SHORTEST
-</pre>
-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 alternative algorithm
-works, this is necessarily the shortest possible match at the first possible
-matching point in the subject string.
-<pre>
-  PCRE_DFA_RESTART
-</pre>
-When <b>pcre_dfa_exec()</b> is called with the PCRE_PARTIAL option, and returns
-a partial match, it is possible to call it again, with additional subject
-characters, and have it continue with the same match. The PCRE_DFA_RESTART
-option requests this action; when it is set, the <i>workspace</i> and
-<i>wscount</i> 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
-<a href="pcrepartial.html"><b>pcrepartial</b></a>
-documentation.
-</P>
-<br><b>
-Successful returns from <b>pcre_dfa_exec()</b>
-</b><br>
-<P>
-When <b>pcre_dfa_exec()</b> succeeds, it may have matched more than one
-substring 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, if the pattern
-<pre>
-  &#60;.*&#62;
-</pre>
-is matched against the string
-<pre>
-  This is &#60;something&#62; &#60;something else&#62; &#60;something further&#62; no more
-</pre>
-the three matched strings are
-<pre>
-  &#60;something&#62;
-  &#60;something&#62; &#60;something else&#62;
-  &#60;something&#62; &#60;something else&#62; &#60;something further&#62;
-</pre>
-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
-<i>ovector</i>. 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 <b>pcre_exec()</b>
-returns data, even though the meaning of the strings is different.)
-</P>
-<P>
-The strings are returned in reverse order of length; that is, the longest
-matching string is given first. If there were too many matches to fit into
-<i>ovector</i>, the yield of the function is zero, and the vector is filled with
-the longest matches.
-</P>
-<br><b>
-Error returns from <b>pcre_dfa_exec()</b>
-</b><br>
-<P>
-The <b>pcre_dfa_exec()</b> function returns a negative number when it fails.
-Many of the errors are the same as for <b>pcre_exec()</b>, and these are
-described
-<a href="#errorlist">above.</a>
-There are in addition the following errors that are specific to
-<b>pcre_dfa_exec()</b>:
-<pre>
-  PCRE_ERROR_DFA_UITEM      (-16)
-</pre>
-This return is given if <b>pcre_dfa_exec()</b> encounters an item in the pattern
-that it does not support, for instance, the use of \C or a back reference.
-<pre>
-  PCRE_ERROR_DFA_UCOND      (-17)
-</pre>
-This return is given if <b>pcre_dfa_exec()</b> 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.
-<pre>
-  PCRE_ERROR_DFA_UMLIMIT    (-18)
-</pre>
-This return is given if <b>pcre_dfa_exec()</b> is called with an <i>extra</i>
-block that contains a setting of the <i>match_limit</i> field. This is not
-supported (it is meaningless).
-<pre>
-  PCRE_ERROR_DFA_WSSIZE     (-19)
-</pre>
-This return is given if <b>pcre_dfa_exec()</b> runs out of space in the
-<i>workspace</i> vector.
-<pre>
-  PCRE_ERROR_DFA_RECURSE    (-20)
-</pre>
-When a recursive subpattern is processed, the matching function calls itself
-recursively, using private vectors for <i>ovector</i> and <i>workspace</i>. 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.
-</P>
-<br><a name="SEC20" href="#TOC1">SEE ALSO</a><br>
-<P>
-<b>pcrebuild</b>(3), <b>pcrecallout</b>(3), <b>pcrecpp(3)</b>(3),
-<b>pcrematching</b>(3), <b>pcrepartial</b>(3), <b>pcreposix</b>(3),
-<b>pcreprecompile</b>(3), <b>pcresample</b>(3), <b>pcrestack</b>(3).
-</P>
-<br><a name="SEC21" href="#TOC1">AUTHOR</a><br>
-<P>
-Philip Hazel
-<br>
-University Computing Service
-<br>
-Cambridge CB2 3QH, England.
-<br>
-</P>
-<br><a name="SEC22" href="#TOC1">REVISION</a><br>
-<P>
-Last updated: 11 September 2007
-<br>
-Copyright &copy; 1997-2007 University of Cambridge.
+Last updated: 09 September 2004
 <br>
+Copyright &copy; 1997-2004 University of Cambridge.
 <p>
 Return to the <a href="index.html">PCRE index page</a>.
 </p>

Modified: httpd/httpd/vendor/pcre/current/doc/html/pcrebuild.html
URL: http://svn.apache.org/viewvc/httpd/httpd/vendor/pcre/current/doc/html/pcrebuild.html?rev=598343&r1=598342&r2=598343&view=diff
==============================================================================
--- httpd/httpd/vendor/pcre/current/doc/html/pcrebuild.html (original)
+++ httpd/httpd/vendor/pcre/current/doc/html/pcrebuild.html Mon Nov 26 09:04:19 2007
@@ -14,56 +14,34 @@
 <br>
 <ul>
 <li><a name="TOC1" href="#SEC1">PCRE BUILD-TIME OPTIONS</a>
-<li><a name="TOC2" href="#SEC2">C++ SUPPORT</a>
-<li><a name="TOC3" href="#SEC3">UTF-8 SUPPORT</a>
-<li><a name="TOC4" href="#SEC4">UNICODE CHARACTER PROPERTY SUPPORT</a>
-<li><a name="TOC5" href="#SEC5">CODE VALUE OF NEWLINE</a>
-<li><a name="TOC6" href="#SEC6">WHAT \R MATCHES</a>
-<li><a name="TOC7" href="#SEC7">BUILDING SHARED AND STATIC LIBRARIES</a>
-<li><a name="TOC8" href="#SEC8">POSIX MALLOC USAGE</a>
-<li><a name="TOC9" href="#SEC9">HANDLING VERY LARGE PATTERNS</a>
-<li><a name="TOC10" href="#SEC10">AVOIDING EXCESSIVE STACK USAGE</a>
-<li><a name="TOC11" href="#SEC11">LIMITING PCRE RESOURCE USAGE</a>
-<li><a name="TOC12" href="#SEC12">CREATING CHARACTER TABLES AT BUILD TIME</a>
-<li><a name="TOC13" href="#SEC13">USING EBCDIC CODE</a>
-<li><a name="TOC14" href="#SEC14">SEE ALSO</a>
-<li><a name="TOC15" href="#SEC15">AUTHOR</a>
-<li><a name="TOC16" href="#SEC16">REVISION</a>
+<li><a name="TOC2" href="#SEC2">UTF-8 SUPPORT</a>
+<li><a name="TOC3" href="#SEC3">UNICODE CHARACTER PROPERTY SUPPORT</a>
+<li><a name="TOC4" href="#SEC4">CODE VALUE OF NEWLINE</a>
+<li><a name="TOC5" href="#SEC5">BUILDING SHARED AND STATIC LIBRARIES</a>
+<li><a name="TOC6" href="#SEC6">POSIX MALLOC USAGE</a>
+<li><a name="TOC7" href="#SEC7">LIMITING PCRE RESOURCE USAGE</a>
+<li><a name="TOC8" href="#SEC8">HANDLING VERY LARGE PATTERNS</a>
+<li><a name="TOC9" href="#SEC9">AVOIDING EXCESSIVE STACK USAGE</a>
+<li><a name="TOC10" href="#SEC10">USING EBCDIC CODE</a>
 </ul>
 <br><a name="SEC1" href="#TOC1">PCRE BUILD-TIME OPTIONS</a><br>
 <P>
 This document describes the optional features of PCRE that can be selected when
-the library is compiled. It assumes use of the <b>configure</b> script, where
-the optional features are selected or deselected by providing options to
-<b>configure</b> before running the <b>make</b> command. However, the same
-options can be selected in both Unix-like and non-Unix-like environments using
-the GUI facility of <b>CMakeSetup</b> if you are using <b>CMake</b> instead of
-<b>configure</b> to build PCRE.
-</P>
-<P>
-The complete list of options for <b>configure</b> (which includes the standard
-ones such as the selection of the installation directory) can be obtained by
-running
+the library is compiled. They are all selected, or deselected, by providing
+options to the <b>configure</b> script that is run before the <b>make</b>
+command. The complete list of options for <b>configure</b> (which includes the
+standard ones such as the selection of the installation directory) can be
+obtained by running
 <pre>
   ./configure --help
 </pre>
-The following sections include descriptions of options whose names begin with
---enable or --disable. These settings specify changes to the defaults for the
+The following sections describe certain options whose names begin with --enable
+or --disable. These settings specify changes to the defaults for the
 <b>configure</b> command. Because of the way that <b>configure</b> works,
 --enable and --disable always come in pairs, so the complementary option always
 exists as well, but as it specifies the default, it is not described.
 </P>
-<br><a name="SEC2" href="#TOC1">C++ SUPPORT</a><br>
-<P>
-By default, the <b>configure</b> script will search for a C++ compiler and C++
-header files. If it finds them, it automatically builds the C++ wrapper library
-for PCRE. You can disable this by adding
-<pre>
-  --disable-cpp
-</pre>
-to the <b>configure</b> command.
-</P>
-<br><a name="SEC3" href="#TOC1">UTF-8 SUPPORT</a><br>
+<br><a name="SEC2" href="#TOC1">UTF-8 SUPPORT</a><br>
 <P>
 To build PCRE with support for UTF-8 character strings, add
 <pre>
@@ -74,7 +52,7 @@
 have to set the PCRE_UTF8 option when you call the <b>pcre_compile()</b>
 function.
 </P>
-<br><a name="SEC4" href="#TOC1">UNICODE CHARACTER PROPERTY SUPPORT</a><br>
+<br><a name="SEC3" href="#TOC1">UNICODE CHARACTER PROPERTY SUPPORT</a><br>
 <P>
 UTF-8 support allows PCRE to process character values greater than 255 in the
 strings that it handles. On its own, however, it does not provide any
@@ -88,57 +66,25 @@
 not explicitly requested it.
 </P>
 <P>
-Including Unicode property support adds around 30K of tables to the PCRE
-library. Only the general category properties such as <i>Lu</i> and <i>Nd</i> are
-supported. Details are given in the
+Including Unicode property support adds around 90K of tables to the PCRE
+library, approximately doubling its size. Only the general category properties
+such as <i>Lu</i> and <i>Nd</i> are supported. Details are given in the
 <a href="pcrepattern.html"><b>pcrepattern</b></a>
 documentation.
 </P>
-<br><a name="SEC5" href="#TOC1">CODE VALUE OF NEWLINE</a><br>
+<br><a name="SEC4" href="#TOC1">CODE VALUE OF NEWLINE</a><br>
 <P>
-By default, PCRE interprets character 10 (linefeed, LF) as indicating the end
-of a line. This is the normal newline character on Unix-like systems. You can
-compile PCRE to use character 13 (carriage return, CR) instead, by adding
+By default, PCRE treats character 10 (linefeed) as the newline character. This
+is the normal newline character on Unix-like systems. You can compile PCRE to
+use character 13 (carriage return) instead by adding
 <pre>
   --enable-newline-is-cr
 </pre>
-to the <b>configure</b> command. There is also a --enable-newline-is-lf option,
-which explicitly specifies linefeed as the newline character.
-<br>
-<br>
-Alternatively, you can specify that line endings are to be indicated by the two
-character sequence CRLF. If you want this, add
-<pre>
-  --enable-newline-is-crlf
-</pre>
-to the <b>configure</b> command. There is a fourth option, specified by
-<pre>
-  --enable-newline-is-anycrlf
-</pre>
-which causes PCRE to recognize any of the three sequences CR, LF, or CRLF as
-indicating a line ending. Finally, a fifth option, specified by
-<pre>
-  --enable-newline-is-any
-</pre>
-causes PCRE to recognize any Unicode newline sequence.
+to the <b>configure</b> command. For completeness there is also a
+--enable-newline-is-lf option, which explicitly specifies linefeed as the
+newline character.
 </P>
-<P>
-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.
-</P>
-<br><a name="SEC6" href="#TOC1">WHAT \R MATCHES</a><br>
-<P>
-By default, the sequence \R in a pattern matches any Unicode newline sequence,
-whatever has been selected as the line ending sequence. If you specify
-<pre>
-  --enable-bsr-anycrlf
-</pre>
-the default is changed so that \R matches only CR, LF, or CRLF. Whatever is
-selected when PCRE is built can be overridden when the library functions are
-called.
-</P>
-<br><a name="SEC7" href="#TOC1">BUILDING SHARED AND STATIC LIBRARIES</a><br>
+<br><a name="SEC5" href="#TOC1">BUILDING SHARED AND STATIC LIBRARIES</a><br>
 <P>
 The PCRE building process uses <b>libtool</b> to build both shared and static
 Unix libraries by default. You can suppress one of these by adding one of
@@ -148,7 +94,7 @@
 </pre>
 to the <b>configure</b> command, as required.
 </P>
-<br><a name="SEC8" href="#TOC1">POSIX MALLOC USAGE</a><br>
+<br><a name="SEC6" href="#TOC1">POSIX MALLOC USAGE</a><br>
 <P>
 When PCRE is called through the POSIX interface (see the
 <a href="pcreposix.html"><b>pcreposix</b></a>
@@ -164,7 +110,22 @@
 </pre>
 to the <b>configure</b> command.
 </P>
-<br><a name="SEC9" href="#TOC1">HANDLING VERY LARGE PATTERNS</a><br>
+<br><a name="SEC7" href="#TOC1">LIMITING PCRE RESOURCE USAGE</a><br>
+<P>
+Internally, PCRE has a function called <b>match()</b>, which it calls repeatedly
+(possibly recursively) when matching a pattern. 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
+<b>pcre_exec()</b>. The limit can be changed at run time, as described in the
+<a href="pcreapi.html"><b>pcreapi</b></a>
+documentation. The default is 10 million, but this can be changed by adding a
+setting such as
+<pre>
+  --with-match-limit=500000
+</pre>
+to the <b>configure</b> command.
+</P>
+<br><a name="SEC8" href="#TOC1">HANDLING VERY LARGE PATTERNS</a><br>
 <P>
 Within a compiled pattern, offset values are used to point from one part to
 another (for example, from an opening parenthesis to an alternation
@@ -180,115 +141,46 @@
 longer offsets slows down the operation of PCRE because it has to load
 additional bytes when handling them.
 </P>
-<br><a name="SEC10" href="#TOC1">AVOIDING EXCESSIVE STACK USAGE</a><br>
 <P>
-When matching with the <b>pcre_exec()</b> function, PCRE implements backtracking
-by making recursive calls to an internal function called <b>match()</b>. In
-environments where the size of the stack is limited, this can severely 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
-<a href="pcrestack.html"><b>pcrestack</b></a>
-documentation.) 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
+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.
+</P>
+<br><a name="SEC9" href="#TOC1">AVOIDING EXCESSIVE STACK USAGE</a><br>
+<P>
+PCRE implements backtracking while matching by making recursive calls to an
+internal function called <b>match()</b>. In environments where the size of the
+stack is limited, this can severely limit PCRE's operation. (The Unix
+environment does not usually suffer from this problem.) An alternative approach
+that uses memory from the heap to remember data, instead of using recursive
+function calls, has been implemented to work round this problem. If you want to
 build a version of PCRE that works this way, add
 <pre>
   --disable-stack-for-recursion
 </pre>
 to the <b>configure</b> command. With this configuration, PCRE will use the
 <b>pcre_stack_malloc</b> and <b>pcre_stack_free</b> variables to call memory
-management functions. By default these point to <b>malloc()</b> and
-<b>free()</b>, but you can replace the pointers so that your own functions are
-used.
-</P>
-<P>
-Separate functions are provided rather than using <b>pcre_malloc</b> and
-<b>pcre_free</b> 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 <b>malloc()</b> and <b>free()</b>. PCRE runs noticeably more
-slowly when built in this way. This option affects only the <b>pcre_exec()</b>
-function; it is not relevant for the the <b>pcre_dfa_exec()</b> function.
+management 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 <b>malloc()</b> and
+<b>free()</b> functions. PCRE runs noticeably more slowly when built in this
+way.
 </P>
-<br><a name="SEC11" href="#TOC1">LIMITING PCRE RESOURCE USAGE</a><br>
-<P>
-Internally, PCRE has a function called <b>match()</b>, which it calls repeatedly
-(sometimes recursively) when matching a pattern with the <b>pcre_exec()</b>
-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 <b>pcre_exec()</b>. The limit can be changed
-at run time, as described in the
-<a href="pcreapi.html"><b>pcreapi</b></a>
-documentation. The default is 10 million, but this can be changed by adding a
-setting such as
-<pre>
-  --with-match-limit=500000
-</pre>
-to the <b>configure</b> command. This setting has no effect on the
-<b>pcre_dfa_exec()</b> matching function.
-</P>
-<P>
-In some environments it is desirable to limit the depth of recursive calls of
-<b>match()</b> more strictly than the total number of calls, in order 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 by adding, for example,
-<pre>
-  --with-match-limit-recursion=10000
-</pre>
-to the <b>configure</b> command. This value can also be overridden at run time.
-</P>
-<br><a name="SEC12" href="#TOC1">CREATING CHARACTER TABLES AT BUILD TIME</a><br>
-<P>
-PCRE uses fixed tables for processing characters whose code values are less
-than 256. By default, PCRE is built with a set of tables that are distributed
-in the file <i>pcre_chartables.c.dist</i>. These tables are for ASCII codes
-only. If you add
-<pre>
-  --enable-rebuild-chartables
-</pre>
-to the <b>configure</b> command, the distributed tables are no longer used.
-Instead, a program called <b>dftables</b> is compiled and run. This outputs the
-source for new set of tables, created in the default locale of your C runtime
-system. (This method of replacing the tables does not work if you are cross
-compiling, because <b>dftables</b> is run on the local host. If you need to
-create alternative tables when cross compiling, you will have to do so "by
-hand".)
-</P>
-<br><a name="SEC13" href="#TOC1">USING EBCDIC CODE</a><br>
+<br><a name="SEC10" href="#TOC1">USING EBCDIC CODE</a><br>
 <P>
 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). This is the case for
-most computer operating systems. PCRE can, however, be compiled to run in an
-EBCDIC environment by adding
+code is ASCII (or Unicode, which is a superset of ASCII). PCRE can, however, be
+compiled to run in an EBCDIC environment by adding
 <pre>
   --enable-ebcdic
 </pre>
-to the <b>configure</b> command. This setting implies
---enable-rebuild-chartables. You should only use it if you know that you are in
-an EBCDIC environment (for example, an IBM mainframe operating system).
-</P>
-<br><a name="SEC14" href="#TOC1">SEE ALSO</a><br>
-<P>
-<b>pcreapi</b>(3), <b>pcre_config</b>(3).
-</P>
-<br><a name="SEC15" href="#TOC1">AUTHOR</a><br>
-<P>
-Philip Hazel
-<br>
-University Computing Service
-<br>
-Cambridge CB2 3QH, England.
-<br>
+to the <b>configure</b> command.
 </P>
-<br><a name="SEC16" href="#TOC1">REVISION</a><br>
 <P>
-Last updated: 21 September 2007
-<br>
-Copyright &copy; 1997-2007 University of Cambridge.
+Last updated: 09 September 2004
 <br>
+Copyright &copy; 1997-2004 University of Cambridge.
 <p>
 Return to the <a href="index.html">PCRE index page</a>.
 </p>



Mime
View raw message