ViewVC logotype

Contents of /code/trunk/doc/html/pcreapi.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 77 - (hide annotations) (download) (as text)
Sat Feb 24 21:40:45 2007 UTC (8 years, 2 months ago) by nigel
File MIME type: text/html
File size: 72054 byte(s)
Load pcre-6.0 into code/trunk.

1 nigel 63 <html>
2     <head>
3     <title>pcreapi specification</title>
4     </head>
5     <body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
6 nigel 75 <h1>pcreapi man page</h1>
7     <p>
8     Return to the <a href="index.html">PCRE index page</a>.
9     </p>
10     <p>
11     This page is part of the PCRE HTML documentation. It was generated automatically
12     from the original man page. If there is any nonsense in it, please consult the
13     man page, in case the conversion went wrong.
14     <br>
15 nigel 63 <ul>
16 nigel 75 <li><a name="TOC1" href="#SEC1">PCRE NATIVE API</a>
17     <li><a name="TOC2" href="#SEC2">PCRE API OVERVIEW</a>
18 nigel 63 <li><a name="TOC3" href="#SEC3">MULTITHREADING</a>
19 nigel 75 <li><a name="TOC4" href="#SEC4">SAVING PRECOMPILED PATTERNS FOR LATER USE</a>
20     <li><a name="TOC5" href="#SEC5">CHECKING BUILD-TIME OPTIONS</a>
21     <li><a name="TOC6" href="#SEC6">COMPILING A PATTERN</a>
22 nigel 77 <li><a name="TOC7" href="#SEC7">COMPILATION ERROR CODES</a>
23     <li><a name="TOC8" href="#SEC8">STUDYING A PATTERN</a>
24     <li><a name="TOC9" href="#SEC9">LOCALE SUPPORT</a>
25     <li><a name="TOC10" href="#SEC10">INFORMATION ABOUT A PATTERN</a>
26     <li><a name="TOC11" href="#SEC11">OBSOLETE INFO FUNCTION</a>
27     <li><a name="TOC12" href="#SEC12">REFERENCE COUNTS</a>
28     <li><a name="TOC13" href="#SEC13">MATCHING A PATTERN: THE TRADITIONAL FUNCTION</a>
29     <li><a name="TOC14" href="#SEC14">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a>
30     <li><a name="TOC15" href="#SEC15">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a>
31     <li><a name="TOC16" href="#SEC16">FINDING ALL POSSIBLE MATCHES</a>
32     <li><a name="TOC17" href="#SEC17">MATCHING A PATTERN: THE ALTERNATIVE FUNCTION</a>
33 nigel 63 </ul>
34 nigel 75 <br><a name="SEC1" href="#TOC1">PCRE NATIVE API</a><br>
35 nigel 63 <P>
36     <b>#include &#60;pcre.h&#62;</b>
37     </P>
38     <P>
39     <b>pcre *pcre_compile(const char *<i>pattern</i>, int <i>options</i>,</b>
40     <b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
41     <b>const unsigned char *<i>tableptr</i>);</b>
42     </P>
43     <P>
44 nigel 77 <b>pcre *pcre_compile2(const char *<i>pattern</i>, int <i>options</i>,</b>
45     <b>int *<i>errorcodeptr</i>,</b>
46     <b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
47     <b>const unsigned char *<i>tableptr</i>);</b>
48     </P>
49     <P>
50 nigel 63 <b>pcre_extra *pcre_study(const pcre *<i>code</i>, int <i>options</i>,</b>
51     <b>const char **<i>errptr</i>);</b>
52     </P>
53     <P>
54     <b>int pcre_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
55     <b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
56     <b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>);</b>
57     </P>
58     <P>
59 nigel 77 <b>int pcre_dfa_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
60     <b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
61     <b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>,</b>
62     <b>int *<i>workspace</i>, int <i>wscount</i>);</b>
63     </P>
64     <P>
65 nigel 63 <b>int pcre_copy_named_substring(const pcre *<i>code</i>,</b>
66     <b>const char *<i>subject</i>, int *<i>ovector</i>,</b>
67     <b>int <i>stringcount</i>, const char *<i>stringname</i>,</b>
68     <b>char *<i>buffer</i>, int <i>buffersize</i>);</b>
69     </P>
70     <P>
71     <b>int pcre_copy_substring(const char *<i>subject</i>, int *<i>ovector</i>,</b>
72     <b>int <i>stringcount</i>, int <i>stringnumber</i>, char *<i>buffer</i>,</b>
73     <b>int <i>buffersize</i>);</b>
74     </P>
75     <P>
76     <b>int pcre_get_named_substring(const pcre *<i>code</i>,</b>
77     <b>const char *<i>subject</i>, int *<i>ovector</i>,</b>
78     <b>int <i>stringcount</i>, const char *<i>stringname</i>,</b>
79     <b>const char **<i>stringptr</i>);</b>
80     </P>
81     <P>
82     <b>int pcre_get_stringnumber(const pcre *<i>code</i>,</b>
83     <b>const char *<i>name</i>);</b>
84     </P>
85     <P>
86     <b>int pcre_get_substring(const char *<i>subject</i>, int *<i>ovector</i>,</b>
87     <b>int <i>stringcount</i>, int <i>stringnumber</i>,</b>
88     <b>const char **<i>stringptr</i>);</b>
89     </P>
90     <P>
91     <b>int pcre_get_substring_list(const char *<i>subject</i>,</b>
92     <b>int *<i>ovector</i>, int <i>stringcount</i>, const char ***<i>listptr</i>);</b>
93     </P>
94     <P>
95     <b>void pcre_free_substring(const char *<i>stringptr</i>);</b>
96     </P>
97     <P>
98     <b>void pcre_free_substring_list(const char **<i>stringptr</i>);</b>
99     </P>
100     <P>
101     <b>const unsigned char *pcre_maketables(void);</b>
102     </P>
103     <P>
104     <b>int pcre_fullinfo(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
105     <b>int <i>what</i>, void *<i>where</i>);</b>
106     </P>
107     <P>
108     <b>int pcre_info(const pcre *<i>code</i>, int *<i>optptr</i>, int</b>
109     <b>*<i>firstcharptr</i>);</b>
110     </P>
111     <P>
112 nigel 77 <b>int pcre_refcount(pcre *<i>code</i>, int <i>adjust</i>);</b>
113     </P>
114     <P>
115 nigel 63 <b>int pcre_config(int <i>what</i>, void *<i>where</i>);</b>
116     </P>
117     <P>
118     <b>char *pcre_version(void);</b>
119     </P>
120     <P>
121     <b>void *(*pcre_malloc)(size_t);</b>
122     </P>
123     <P>
124     <b>void (*pcre_free)(void *);</b>
125     </P>
126     <P>
127 nigel 73 <b>void *(*pcre_stack_malloc)(size_t);</b>
128     </P>
129     <P>
130     <b>void (*pcre_stack_free)(void *);</b>
131     </P>
132     <P>
133 nigel 63 <b>int (*pcre_callout)(pcre_callout_block *);</b>
134     </P>
135 nigel 75 <br><a name="SEC2" href="#TOC1">PCRE API OVERVIEW</a><br>
136 nigel 63 <P>
137 nigel 77 PCRE has its own native API, which is described in this document. There is
138     also a set of wrapper functions that correspond to the POSIX regular expression
139     API. These are described in the
140 nigel 75 <a href="pcreposix.html"><b>pcreposix</b></a>
141 nigel 77 documentation. Both of these APIs define a set of C function calls. A C++
142     wrapper is distributed with PCRE. It is documented in the
143     <a href="pcrecpp.html"><b>pcrecpp</b></a>
144     page.
145 nigel 63 </P>
146     <P>
147 nigel 77 The native API C function prototypes are defined in the header file
148     <b>pcre.h</b>, and on Unix systems the library itself is called <b>libpcre</b>.
149     It can normally be accessed by adding <b>-lpcre</b> to the command for linking
150     an application that uses PCRE. The header file defines the macros PCRE_MAJOR
151     and PCRE_MINOR to contain the major and minor release numbers for the library.
152 nigel 75 Applications can use these to include support for different releases of PCRE.
153 nigel 63 </P>
154     <P>
155 nigel 77 The functions <b>pcre_compile()</b>, <b>pcre_compile2()</b>, <b>pcre_study()</b>,
156     and <b>pcre_exec()</b> are used for compiling and matching regular expressions
157     in a Perl-compatible manner. A sample program that demonstrates the simplest
158     way of using them is provided in the file called <i>pcredemo.c</i> in the source
159     distribution. The
160 nigel 75 <a href="pcresample.html"><b>pcresample</b></a>
161     documentation describes how to run it.
162 nigel 63 </P>
163     <P>
164 nigel 77 A second matching function, <b>pcre_dfa_exec()</b>, which is not
165     Perl-compatible, is also provided. This uses a different algorithm for the
166     matching. This allows it to find all possible matches (at a given point in the
167     subject), not just one. However, this algorithm does not return captured
168     substrings. A description of the two matching algorithms and their advantages
169     and disadvantages is given in the
170     <a href="pcrematching.html"><b>pcrematching</b></a>
171     documentation.
172     </P>
173     <P>
174 nigel 75 In addition to the main compiling and matching functions, there are convenience
175 nigel 77 functions for extracting captured substrings from a subject string that is
176     matched by <b>pcre_exec()</b>. They are:
177 nigel 63 <pre>
178     <b>pcre_copy_substring()</b>
179     <b>pcre_copy_named_substring()</b>
180     <b>pcre_get_substring()</b>
181     <b>pcre_get_named_substring()</b>
182     <b>pcre_get_substring_list()</b>
183 nigel 75 <b>pcre_get_stringnumber()</b>
184     </pre>
185 nigel 63 <b>pcre_free_substring()</b> and <b>pcre_free_substring_list()</b> are also
186     provided, to free the memory used for extracted strings.
187     </P>
188     <P>
189 nigel 75 The function <b>pcre_maketables()</b> is used to build a set of character tables
190 nigel 77 in the current locale for passing to <b>pcre_compile()</b>, <b>pcre_exec()</b>,
191     or <b>pcre_dfa_exec()</b>. This is an optional facility that is provided for
192     specialist use. Most commonly, no special tables are passed, in which case
193     internal tables that are generated when PCRE is built are used.
194 nigel 63 </P>
195     <P>
196     The function <b>pcre_fullinfo()</b> is used to find out information about a
197 nigel 75 compiled pattern; <b>pcre_info()</b> is an obsolete version that returns only
198 nigel 63 some of the available information, but is retained for backwards compatibility.
199     The function <b>pcre_version()</b> returns a pointer to a string containing the
200     version of PCRE and its date of release.
201     </P>
202     <P>
203 nigel 77 The function <b>pcre_refcount()</b> maintains a reference count in a data block
204     containing a compiled pattern. This is provided for the benefit of
205     object-oriented applications.
206     </P>
207     <P>
208 nigel 63 The global variables <b>pcre_malloc</b> and <b>pcre_free</b> initially contain
209 nigel 75 the entry points of the standard <b>malloc()</b> and <b>free()</b> functions,
210 nigel 63 respectively. PCRE calls the memory management functions via these variables,
211     so a calling program can replace them if it wishes to intercept the calls. This
212     should be done before calling any PCRE functions.
213     </P>
214     <P>
215 nigel 73 The global variables <b>pcre_stack_malloc</b> and <b>pcre_stack_free</b> are also
216     indirections to memory management functions. These special functions are used
217     only when PCRE is compiled to use the heap for remembering data, instead of
218 nigel 77 recursive function calls, when running the <b>pcre_exec()</b> function. This is
219     a non-standard way of building PCRE, for use in environments that have limited
220     stacks. Because of the greater use of memory management, it runs more slowly.
221     Separate functions are provided so that special-purpose external code can be
222     used for this case. When used, these functions are always called in a
223     stack-like manner (last obtained, first freed), and always for memory blocks of
224     the same size.
225 nigel 73 </P>
226     <P>
227 nigel 63 The global variable <b>pcre_callout</b> initially contains NULL. It can be set
228     by the caller to a "callout" function, which PCRE will then call at specified
229 nigel 75 points during a matching operation. Details are given in the
230     <a href="pcrecallout.html"><b>pcrecallout</b></a>
231 nigel 63 documentation.
232     </P>
233     <br><a name="SEC3" href="#TOC1">MULTITHREADING</a><br>
234     <P>
235     The PCRE functions can be used in multi-threading applications, with the
236 nigel 73 proviso that the memory management functions pointed to by <b>pcre_malloc</b>,
237     <b>pcre_free</b>, <b>pcre_stack_malloc</b>, and <b>pcre_stack_free</b>, and the
238     callout function pointed to by <b>pcre_callout</b>, are shared by all threads.
239 nigel 63 </P>
240     <P>
241     The compiled form of a regular expression is not altered during matching, so
242     the same compiled pattern can safely be used by several threads at once.
243     </P>
244 nigel 75 <br><a name="SEC4" href="#TOC1">SAVING PRECOMPILED PATTERNS FOR LATER USE</a><br>
245 nigel 63 <P>
246 nigel 75 The compiled form of a regular expression can be saved and re-used at a later
247     time, possibly by a different program, and even on a host other than the one on
248     which it was compiled. Details are given in the
249     <a href="pcreprecompile.html"><b>pcreprecompile</b></a>
250     documentation.
251     </P>
252     <br><a name="SEC5" href="#TOC1">CHECKING BUILD-TIME OPTIONS</a><br>
253     <P>
254 nigel 63 <b>int pcre_config(int <i>what</i>, void *<i>where</i>);</b>
255     </P>
256     <P>
257     The function <b>pcre_config()</b> makes it possible for a PCRE client to
258     discover which optional features have been compiled into the PCRE library. The
259     <a href="pcrebuild.html"><b>pcrebuild</b></a>
260     documentation has more details about these optional features.
261     </P>
262     <P>
263     The first argument for <b>pcre_config()</b> is an integer, specifying which
264     information is required; the second argument is a pointer to a variable into
265     which the information is placed. The following information is available:
266     <pre>
268 nigel 75 </pre>
269 nigel 63 The output is an integer that is set to one if UTF-8 support is available;
270     otherwise it is set to zero.
271     <pre>
273     </pre>
274     The output is an integer that is set to one if support for Unicode character
275     properties is available; otherwise it is set to zero.
276     <pre>
278 nigel 75 </pre>
279 nigel 63 The output is an integer that is set to the value of the code that is used for
280     the newline character. It is either linefeed (10) or carriage return (13), and
281     should normally be the standard character for your operating system.
282     <pre>
284 nigel 75 </pre>
285 nigel 63 The output is an integer that contains the number of bytes used for internal
286     linkage in compiled regular expressions. The value is 2, 3, or 4. Larger values
287     allow larger regular expressions to be compiled, at the expense of slower
288     matching. The default value of 2 is sufficient for all but the most massive
289     patterns, since it allows the compiled pattern to be up to 64K in size.
290     <pre>
292 nigel 75 </pre>
293 nigel 63 The output is an integer that contains the threshold above which the POSIX
294     interface uses <b>malloc()</b> for output vectors. Further details are given in
295 nigel 75 the
296     <a href="pcreposix.html"><b>pcreposix</b></a>
297     documentation.
298 nigel 63 <pre>
300 nigel 75 </pre>
301 nigel 63 The output is an integer that gives the default limit for the number of
302     internal matching function calls in a <b>pcre_exec()</b> execution. Further
303     details are given with <b>pcre_exec()</b> below.
304 nigel 73 <pre>
306 nigel 75 </pre>
307 nigel 77 The output is an integer that is set to one if internal recursion when running
308     <b>pcre_exec()</b> is implemented by recursive function calls that use the stack
309     to remember their state. This is the usual way that PCRE is compiled. The
310     output is zero if PCRE was compiled to use blocks of data on the heap instead
311     of recursive function calls. In this case, <b>pcre_stack_malloc</b> and
312     <b>pcre_stack_free</b> are called to manage memory blocks on the heap, thus
313     avoiding the use of the stack.
314 nigel 73 </P>
315 nigel 75 <br><a name="SEC6" href="#TOC1">COMPILING A PATTERN</a><br>
316 nigel 63 <P>
317     <b>pcre *pcre_compile(const char *<i>pattern</i>, int <i>options</i>,</b>
318     <b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
319     <b>const unsigned char *<i>tableptr</i>);</b>
320 nigel 77 <b>pcre *pcre_compile2(const char *<i>pattern</i>, int <i>options</i>,</b>
321     <b>int *<i>errorcodeptr</i>,</b>
322     <b>const char **<i>errptr</i>, int *<i>erroffset</i>,</b>
323     <b>const unsigned char *<i>tableptr</i>);</b>
324 nigel 63 </P>
325     <P>
326 nigel 77 Either of the functions <b>pcre_compile()</b> or <b>pcre_compile2()</b> can be
327     called to compile a pattern into an internal form. The only difference between
328     the two interfaces is that <b>pcre_compile2()</b> has an additional argument,
329     <i>errorcodeptr</i>, via which a numerical error code can be returned.
330 nigel 63 </P>
331     <P>
332 nigel 77 The pattern is a C string terminated by a binary zero, and is passed in the
333     <i>pattern</i> argument. A pointer to a single block of memory that is obtained
334     via <b>pcre_malloc</b> is returned. This contains the compiled code and related
335     data. The <b>pcre</b> type is defined for the returned block; this is a typedef
336     for a structure whose contents are not externally defined. It is up to the
337     caller to free the memory when it is no longer required.
338     </P>
339     <P>
340 nigel 63 Although the compiled code of a PCRE regex is relocatable, that is, it does not
341     depend on memory location, the complete <b>pcre</b> data block is not
342 nigel 75 fully relocatable, because it may contain a copy of the <i>tableptr</i>
343     argument, which is an address (see below).
344 nigel 63 </P>
345     <P>
346     The <i>options</i> argument contains independent bits that affect the
347 nigel 75 compilation. It should be zero if no options are required. The available
348     options are described below. Some of them, in particular, those that are
349     compatible with Perl, can also be set and unset from within the pattern (see
350     the detailed description in the
351     <a href="pcrepattern.html"><b>pcrepattern</b></a>
352     documentation). For these options, the contents of the <i>options</i> argument
353     specifies their initial settings at the start of compilation and execution. The
354     PCRE_ANCHORED option can be set at the time of matching as well as at compile
355     time.
356 nigel 63 </P>
357     <P>
358     If <i>errptr</i> is NULL, <b>pcre_compile()</b> returns NULL immediately.
359     Otherwise, if compilation of a pattern fails, <b>pcre_compile()</b> returns
360     NULL, and sets the variable pointed to by <i>errptr</i> to point to a textual
361     error message. The offset from the start of the pattern to the character where
362     the error was discovered is placed in the variable pointed to by
363     <i>erroffset</i>, which must not be NULL. If it is, an immediate error is given.
364     </P>
365     <P>
366 nigel 77 If <b>pcre_compile2()</b> is used instead of <b>pcre_compile()</b>, and the
367     <i>errorcodeptr</i> argument is not NULL, a non-zero error code number is
368     returned via this argument in the event of an error. This is in addition to the
369     textual error message. Error codes and messages are listed below.
370     </P>
371     <P>
372 nigel 63 If the final argument, <i>tableptr</i>, is NULL, PCRE uses a default set of
373 nigel 75 character tables that are built when PCRE is compiled, using the default C
374     locale. Otherwise, <i>tableptr</i> must be an address that is the result of a
375     call to <b>pcre_maketables()</b>. This value is stored with the compiled
376     pattern, and used again by <b>pcre_exec()</b>, unless another table pointer is
377     passed to it. For more discussion, see the section on locale support below.
378 nigel 63 </P>
379     <P>
380     This code fragment shows a typical straightforward call to <b>pcre_compile()</b>:
381     <pre>
382     pcre *re;
383     const char *error;
384     int erroffset;
385     re = pcre_compile(
386     "^A.*Z", /* the pattern */
387     0, /* default options */
388     &error, /* for error message */
389     &erroffset, /* for error offset */
390     NULL); /* use default character tables */
391 nigel 75 </pre>
392     The following names for option bits are defined in the <b>pcre.h</b> header
393     file:
394 nigel 63 <pre>
396 nigel 75 </pre>
397 nigel 63 If this bit is set, the pattern is forced to be "anchored", that is, it is
398 nigel 75 constrained to match only at the first matching point in the string that is
399 nigel 63 being searched (the "subject string"). This effect can also be achieved by
400     appropriate constructs in the pattern itself, which is the only way to do it in
401     Perl.
402     <pre>
403 nigel 75 PCRE_AUTO_CALLOUT
404     </pre>
405     If this bit is set, <b>pcre_compile()</b> automatically inserts callout items,
406     all with number 255, before each pattern item. For discussion of the callout
407     facility, see the
408     <a href="pcrecallout.html"><b>pcrecallout</b></a>
409     documentation.
410     <pre>
411 nigel 63 PCRE_CASELESS
412 nigel 75 </pre>
413 nigel 63 If this bit is set, letters in the pattern match both upper and lower case
414     letters. It is equivalent to Perl's /i option, and it can be changed within a
415 nigel 77 pattern by a (?i) option setting. In UTF-8 mode, PCRE always understands the
416     concept of case for characters whose values are less than 128, so caseless
417     matching is always possible. For characters with higher values, the concept of
418     case is supported if PCRE is compiled with Unicode property support, but not
419     otherwise. If you want to use caseless matching for characters 128 and above,
420     you must ensure that PCRE is compiled with Unicode property support as well as
421     with UTF-8 support.
422 nigel 63 <pre>
424 nigel 75 </pre>
425 nigel 63 If this bit is set, a dollar metacharacter in the pattern matches only at the
426     end of the subject string. Without this option, a dollar also matches
427     immediately before the final character if it is a newline (but not before any
428     other newlines). The PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is
429     set. There is no equivalent to this option in Perl, and no way to set it within
430     a pattern.
431     <pre>
433 nigel 75 </pre>
434 nigel 63 If this bit is set, a dot metacharater in the pattern matches all characters,
435     including newlines. Without it, newlines are excluded. This option is
436     equivalent to Perl's /s option, and it can be changed within a pattern by a
437     (?s) option setting. A negative class such as [^a] always matches a newline
438     character, independent of the setting of this option.
439     <pre>
441 nigel 75 </pre>
442 nigel 63 If this bit is set, whitespace data characters in the pattern are totally
443     ignored except when escaped or inside a character class. Whitespace does not
444     include the VT character (code 11). In addition, characters between an
445     unescaped # outside a character class and the next newline character,
446     inclusive, are also ignored. This is equivalent to Perl's /x option, and it can
447     be changed within a pattern by a (?x) option setting.
448     </P>
449     <P>
450     This option makes it possible to include comments inside complicated patterns.
451     Note, however, that this applies only to data characters. Whitespace characters
452     may never appear within special character sequences in a pattern, for example
453     within the sequence (?( which introduces a conditional subpattern.
454     <pre>
455     PCRE_EXTRA
456 nigel 75 </pre>
457 nigel 63 This option was invented in order to turn on additional functionality of PCRE
458     that is incompatible with Perl, but it is currently of very little use. When
459     set, any backslash in a pattern that is followed by a letter that has no
460     special meaning causes an error, thus reserving these combinations for future
461     expansion. By default, as in Perl, a backslash followed by a letter with no
462     special meaning is treated as a literal. There are at present no other features
463     controlled by this option. It can also be set by a (?X) option setting within a
464     pattern.
465     <pre>
466 nigel 77 PCRE_FIRSTLINE
467     </pre>
468     If this option is set, an unanchored pattern is required to match before or at
469     the first newline character in the subject string, though the matched text may
470     continue over the newline.
471     <pre>
472 nigel 63 PCRE_MULTILINE
473 nigel 75 </pre>
474     By default, PCRE treats the subject string as consisting of a single line of
475     characters (even if it actually contains newlines). The "start of line"
476 nigel 63 metacharacter (^) matches only at the start of the string, while the "end of
477     line" metacharacter ($) matches only at the end of the string, or before a
478     terminating newline (unless PCRE_DOLLAR_ENDONLY is set). This is the same as
479     Perl.
480     </P>
481     <P>
482     When PCRE_MULTILINE it is set, the "start of line" and "end of line" constructs
483     match immediately following or immediately before any newline in the subject
484     string, respectively, as well as at the very start and end. This is equivalent
485     to Perl's /m option, and it can be changed within a pattern by a (?m) option
486     setting. If there are no "\n" characters in a subject string, or no
487     occurrences of ^ or $ in a pattern, setting PCRE_MULTILINE has no effect.
488     <pre>
490 nigel 75 </pre>
491 nigel 63 If this option is set, it disables the use of numbered capturing parentheses in
492     the pattern. Any opening parenthesis that is not followed by ? behaves as if it
493     were followed by ?: but named parentheses can still be used for capturing (and
494     they acquire numbers in the usual way). There is no equivalent of this option
495     in Perl.
496     <pre>
498 nigel 75 </pre>
499 nigel 63 This option inverts the "greediness" of the quantifiers so that they are not
500     greedy by default, but become greedy if followed by "?". It is not compatible
501     with Perl. It can also be set by a (?U) option setting within the pattern.
502     <pre>
503     PCRE_UTF8
504 nigel 75 </pre>
505 nigel 63 This option causes PCRE to regard both the pattern and the subject as strings
506     of UTF-8 characters instead of single-byte character strings. However, it is
507 nigel 75 available only when PCRE is built to include UTF-8 support. If not, the use
508 nigel 63 of this option provokes an error. Details of how this option changes the
509     behaviour of PCRE are given in the
510     <a href="pcre.html#utf8support">section on UTF-8 support</a>
511     in the main
512     <a href="pcre.html"><b>pcre</b></a>
513     page.
514 nigel 71 <pre>
516 nigel 75 </pre>
517 nigel 71 When PCRE_UTF8 is set, the validity of the pattern as a UTF-8 string is
518     automatically checked. If an invalid UTF-8 sequence of bytes is found,
519     <b>pcre_compile()</b> returns an error. If you already know that your pattern is
520     valid, and you want to skip this check for performance reasons, you can set the
521     PCRE_NO_UTF8_CHECK option. When it is set, the effect of passing an invalid
522     UTF-8 string as a pattern is undefined. It may cause your program to crash.
523 nigel 77 Note that this option can also be passed to <b>pcre_exec()</b> and
524     <b>pcre_dfa_exec()</b>, to suppress the UTF-8 validity checking of subject
525     strings.
526 nigel 71 </P>
527 nigel 77 <br><a name="SEC7" href="#TOC1">COMPILATION ERROR CODES</a><br>
528 nigel 63 <P>
529 nigel 77 The following table lists the error codes than may be returned by
530     <b>pcre_compile2()</b>, along with the error messages that may be returned by
531     both compiling functions.
532     <pre>
533     0 no error
534     1 \ at end of pattern
535     2 \c at end of pattern
536     3 unrecognized character follows \
537     4 numbers out of order in {} quantifier
538     5 number too big in {} quantifier
539     6 missing terminating ] for character class
540     7 invalid escape sequence in character class
541     8 range out of order in character class
542     9 nothing to repeat
543     10 operand of unlimited repeat could match the empty string
544     11 internal error: unexpected repeat
545     12 unrecognized character after (?
546     13 POSIX named classes are supported only within a class
547     14 missing )
548     15 reference to non-existent subpattern
549     16 erroffset passed as NULL
550     17 unknown option bit(s) set
551     18 missing ) after comment
552     19 parentheses nested too deeply
553     20 regular expression too large
554     21 failed to get memory
555     22 unmatched parentheses
556     23 internal error: code overflow
557     24 unrecognized character after (?&#60;
558     25 lookbehind assertion is not fixed length
559     26 malformed number after (?(
560     27 conditional group contains more than two branches
561     28 assertion expected after (?(
562     29 (?R or (?digits must be followed by )
563     30 unknown POSIX class name
564     31 POSIX collating elements are not supported
565     32 this version of PCRE is not compiled with PCRE_UTF8 support
566     33 spare error
567     34 character value in \x{...} sequence is too large
568     35 invalid condition (?(0)
569     36 \C not allowed in lookbehind assertion
570     37 PCRE does not support \L, \l, \N, \U, or \u
571     38 number after (?C is &#62; 255
572     39 closing ) for (?C expected
573     40 recursive call could loop indefinitely
574     41 unrecognized character after (?P
575     42 syntax error after (?P
576     43 two named groups have the same name
577     44 invalid UTF-8 string
578     45 support for \P, \p, and \X has not been compiled
579     46 malformed \P or \p sequence
580     47 unknown property name after \P or \p
581     </PRE>
582     </P>
583     <br><a name="SEC8" href="#TOC1">STUDYING A PATTERN</a><br>
584     <P>
585     <b>pcre_extra *pcre_study(const pcre *<i>code</i>, int <i>options</i></b>
586 nigel 63 <b>const char **<i>errptr</i>);</b>
587     </P>
588     <P>
589 nigel 75 If a compiled pattern is going to be used several times, it is worth spending
590     more time analyzing it in order to speed up the time taken for matching. The
591 nigel 63 function <b>pcre_study()</b> takes a pointer to a compiled pattern as its first
592 nigel 75 argument. If studying the pattern produces additional information that will
593     help speed up matching, <b>pcre_study()</b> returns a pointer to a
594     <b>pcre_extra</b> block, in which the <i>study_data</i> field points to the
595     results of the study.
596 nigel 63 </P>
597     <P>
598 nigel 75 The returned value from <b>pcre_study()</b> can be passed directly to
599     <b>pcre_exec()</b>. However, a <b>pcre_extra</b> block also contains other
600 nigel 63 fields that can be set by the caller before the block is passed; these are
601 nigel 75 described
602     <a href="#extradata">below</a>
603     in the section on matching a pattern.
604 nigel 63 </P>
605     <P>
606 nigel 77 If studying the pattern does not produce any additional information
607 nigel 75 <b>pcre_study()</b> returns NULL. In that circumstance, if the calling program
608     wants to pass any of the other fields to <b>pcre_exec()</b>, it must set up its
609     own <b>pcre_extra</b> block.
610 nigel 63 </P>
611     <P>
612 nigel 75 The second argument of <b>pcre_study()</b> contains option bits. At present, no
613     options are defined, and this argument should always be zero.
614     </P>
615     <P>
616 nigel 63 The third argument for <b>pcre_study()</b> is a pointer for an error message. If
617     studying succeeds (even if no data is returned), the variable it points to is
618     set to NULL. Otherwise it points to a textual error message. You should
619     therefore test the error pointer for NULL after calling <b>pcre_study()</b>, to
620     be sure that it has run successfully.
621     </P>
622     <P>
623     This is a typical call to <b>pcre_study</b>():
624     <pre>
625     pcre_extra *pe;
626     pe = pcre_study(
627     re, /* result of pcre_compile() */
628     0, /* no options exist */
629     &error); /* set to NULL or points to a message */
630 nigel 75 </pre>
631 nigel 63 At present, studying a pattern is useful only for non-anchored patterns that do
632     not have a single fixed starting character. A bitmap of possible starting
633 nigel 75 bytes is created.
634     <a name="localesupport"></a></P>
635 nigel 77 <br><a name="SEC9" href="#TOC1">LOCALE SUPPORT</a><br>
636 nigel 63 <P>
637 nigel 77 PCRE handles caseless matching, and determines whether characters are letters
638 nigel 75 digits, or whatever, by reference to a set of tables, indexed by character
639 nigel 77 value. When running in UTF-8 mode, this applies only to characters with codes
640 nigel 75 less than 128. Higher-valued codes never match escapes such as \w or \d, but
641     can be tested with \p if PCRE is built with Unicode character property
642 nigel 77 support.
643 nigel 63 </P>
644     <P>
645 nigel 75 An internal set of tables is created in the default C locale when PCRE is
646     built. This is used when the final argument of <b>pcre_compile()</b> is NULL,
647     and is sufficient for many applications. An alternative set of tables can,
648     however, be supplied. These may be created in a different locale from the
649     default. As more and more applications change to using Unicode, the need for
650     this locale support is expected to die away.
651 nigel 63 </P>
652     <P>
653 nigel 75 External tables are built by calling the <b>pcre_maketables()</b> function,
654     which has no arguments, in the relevant locale. The result can then be passed
655     to <b>pcre_compile()</b> or <b>pcre_exec()</b> as often as necessary. For
656     example, to build and use tables that are appropriate for the French locale
657     (where accented characters with values greater than 128 are treated as letters),
658     the following code could be used:
659 nigel 63 <pre>
660 nigel 75 setlocale(LC_CTYPE, "fr_FR");
661 nigel 63 tables = pcre_maketables();
662     re = pcre_compile(..., tables);
663 nigel 75 </pre>
664     When <b>pcre_maketables()</b> runs, the tables are built in memory that is
665     obtained via <b>pcre_malloc</b>. It is the caller's responsibility to ensure
666     that the memory containing the tables remains available for as long as it is
667     needed.
668 nigel 63 </P>
669     <P>
670 nigel 75 The pointer that is passed to <b>pcre_compile()</b> is saved with the compiled
671 nigel 63 pattern, and the same tables are used via this pointer by <b>pcre_study()</b>
672 nigel 75 and normally also by <b>pcre_exec()</b>. Thus, by default, for any single
673     pattern, compilation, studying and matching all happen in the same locale, but
674     different patterns can be compiled in different locales.
675 nigel 63 </P>
676     <P>
677 nigel 75 It is possible to pass a table pointer or NULL (indicating the use of the
678     internal tables) to <b>pcre_exec()</b>. Although not intended for this purpose,
679     this facility could be used to match a pattern in a different locale from the
680     one in which it was compiled. Passing table pointers at run time is discussed
681     below in the section on matching a pattern.
682     </P>
683 nigel 77 <br><a name="SEC10" href="#TOC1">INFORMATION ABOUT A PATTERN</a><br>
684 nigel 75 <P>
685 nigel 63 <b>int pcre_fullinfo(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
686     <b>int <i>what</i>, void *<i>where</i>);</b>
687     </P>
688     <P>
689     The <b>pcre_fullinfo()</b> function returns information about a compiled
690     pattern. It replaces the obsolete <b>pcre_info()</b> function, which is
691     nevertheless retained for backwards compability (and is documented below).
692     </P>
693     <P>
694     The first argument for <b>pcre_fullinfo()</b> is a pointer to the compiled
695     pattern. The second argument is the result of <b>pcre_study()</b>, or NULL if
696     the pattern was not studied. The third argument specifies which piece of
697     information is required, and the fourth argument is a pointer to a variable
698     to receive the data. The yield of the function is zero for success, or one of
699     the following negative numbers:
700     <pre>
701     PCRE_ERROR_NULL the argument <i>code</i> was NULL
702     the argument <i>where</i> was NULL
703     PCRE_ERROR_BADMAGIC the "magic number" was not found
704     PCRE_ERROR_BADOPTION the value of <i>what</i> was invalid
705 nigel 75 </pre>
706     The "magic number" is placed at the start of each compiled pattern as an simple
707     check against passing an arbitrary memory pointer. Here is a typical call of
708     <b>pcre_fullinfo()</b>, to obtain the length of the compiled pattern:
709 nigel 63 <pre>
710     int rc;
711     unsigned long int length;
712     rc = pcre_fullinfo(
713     re, /* result of pcre_compile() */
714     pe, /* result of pcre_study(), or NULL */
715     PCRE_INFO_SIZE, /* what is required */
716     &length); /* where to put the data */
717 nigel 75 </pre>
718 nigel 63 The possible values for the third argument are defined in <b>pcre.h</b>, and are
719     as follows:
720     <pre>
722 nigel 75 </pre>
723 nigel 63 Return the number of the highest back reference in the pattern. The fourth
724     argument should point to an <b>int</b> variable. Zero is returned if there are
725     no back references.
726     <pre>
728 nigel 75 </pre>
729 nigel 63 Return the number of capturing subpatterns in the pattern. The fourth argument
730 nigel 75 should point to an <b>int</b> variable.
731 nigel 63 <pre>
733 nigel 75 </pre>
734     Return a pointer to the internal default character tables within PCRE. The
735     fourth argument should point to an <b>unsigned char *</b> variable. This
736     information call is provided for internal use by the <b>pcre_study()</b>
737     function. External callers can cause PCRE to use its internal tables by passing
738     a NULL table pointer.
739     <pre>
741 nigel 75 </pre>
742 nigel 63 Return information about the first byte of any matched string, for a
743     non-anchored pattern. (This option used to be called PCRE_INFO_FIRSTCHAR; the
744     old name is still recognized for backwards compatibility.)
745     </P>
746     <P>
747 nigel 75 If there is a fixed first byte, for example, from a pattern such as
748     (cat|cow|coyote), it is returned in the integer pointed to by <i>where</i>.
749     Otherwise, if either
750     <br>
751     <br>
752 nigel 63 (a) the pattern was compiled with the PCRE_MULTILINE option, and every branch
753     starts with "^", or
754 nigel 75 <br>
755     <br>
756 nigel 63 (b) every branch of the pattern starts with ".*" and PCRE_DOTALL is not set
757     (if it were set, the pattern would be anchored),
758 nigel 75 <br>
759     <br>
760 nigel 63 -1 is returned, indicating that the pattern matches only at the start of a
761     subject string or after any newline within the string. Otherwise -2 is
762     returned. For anchored patterns, -2 is returned.
763     <pre>
765 nigel 75 </pre>
766 nigel 63 If the pattern was studied, and this resulted in the construction of a 256-bit
767     table indicating a fixed set of bytes for the first byte in any matching
768     string, a pointer to the table is returned. Otherwise NULL is returned. The
769     fourth argument should point to an <b>unsigned char *</b> variable.
770     <pre>
772 nigel 75 </pre>
773 nigel 65 Return the value of the rightmost literal byte that must exist in any matched
774     string, other than at its start, if such a byte has been recorded. The fourth
775     argument should point to an <b>int</b> variable. If there is no such byte, -1 is
776     returned. For anchored patterns, a last literal byte is recorded only if it
777     follows something of variable length. For example, for the pattern
778     /^a\d+z\d+/ the returned value is "z", but for /^a\dz\d/ the returned value
779     is -1.
780 nigel 63 <pre>
784 nigel 75 </pre>
785 nigel 63 PCRE supports the use of named as well as numbered capturing parentheses. The
786     names are just an additional way of identifying the parentheses, which still
787 nigel 75 acquire numbers. A convenience function called <b>pcre_get_named_substring()</b>
788     is provided for extracting an individual captured substring by name. It is also
789     possible to extract the data directly, by first converting the name to a number
790     in order to access the correct pointers in the output vector (described with
791     <b>pcre_exec()</b> below). To do the conversion, you need to use the
792     name-to-number map, which is described by these three values.
793 nigel 63 </P>
794     <P>
795     The map consists of a number of fixed-size entries. PCRE_INFO_NAMECOUNT gives
796     the number of entries, and PCRE_INFO_NAMEENTRYSIZE gives the size of each
797     entry; both of these return an <b>int</b> value. The entry size depends on the
798     length of the longest name. PCRE_INFO_NAMETABLE returns a pointer to the first
799     entry of the table (a pointer to <b>char</b>). The first two bytes of each entry
800     are the number of the capturing parenthesis, most significant byte first. The
801     rest of the entry is the corresponding name, zero terminated. The names are in
802     alphabetical order. For example, consider the following pattern (assume
803     PCRE_EXTENDED is set, so white space - including newlines - is ignored):
804     <pre>
805 nigel 75 (?P&#60;date&#62; (?P&#60;year&#62;(\d\d)?\d\d) - (?P&#60;month&#62;\d\d) - (?P&#60;day&#62;\d\d) )
806     </pre>
807 nigel 63 There are four named subpatterns, so the table has four entries, and each entry
808     in the table is eight bytes long. The table is as follows, with non-printing
809 nigel 75 bytes shows in hexadecimal, and undefined bytes shown as ??:
810 nigel 63 <pre>
811     00 01 d a t e 00 ??
812     00 05 d a y 00 ?? ??
813     00 04 m o n t h 00
814     00 02 y e a r 00 ??
815 nigel 75 </pre>
816     When writing code to extract data from named subpatterns using the
817     name-to-number map, remember that the length of each entry is likely to be
818     different for each compiled pattern.
819 nigel 63 <pre>
821 nigel 75 </pre>
822 nigel 63 Return a copy of the options with which the pattern was compiled. The fourth
823     argument should point to an <b>unsigned long int</b> variable. These option bits
824     are those specified in the call to <b>pcre_compile()</b>, modified by any
825     top-level option settings within the pattern itself.
826     </P>
827     <P>
828     A pattern is automatically anchored by PCRE if all of its top-level
829     alternatives begin with one of the following:
830     <pre>
831     ^ unless PCRE_MULTILINE is set
832     \A always
833     \G always
834 nigel 75 .* if PCRE_DOTALL is set and there are no back references to the subpattern in which .* appears
835     </pre>
836 nigel 63 For such patterns, the PCRE_ANCHORED bit is set in the options returned by
837     <b>pcre_fullinfo()</b>.
838     <pre>
840 nigel 75 </pre>
841 nigel 63 Return the size of the compiled pattern, that is, the value that was passed as
842     the argument to <b>pcre_malloc()</b> when PCRE was getting memory in which to
843     place the compiled data. The fourth argument should point to a <b>size_t</b>
844     variable.
845     <pre>
847 nigel 75 </pre>
848     Return the size of the data block pointed to by the <i>study_data</i> field in
849 nigel 63 a <b>pcre_extra</b> block. That is, it is the value that was passed to
850     <b>pcre_malloc()</b> when PCRE was getting memory into which to place the data
851     created by <b>pcre_study()</b>. The fourth argument should point to a
852     <b>size_t</b> variable.
853     </P>
854 nigel 77 <br><a name="SEC11" href="#TOC1">OBSOLETE INFO FUNCTION</a><br>
855 nigel 63 <P>
856     <b>int pcre_info(const pcre *<i>code</i>, int *<i>optptr</i>, int</b>
857     <b>*<i>firstcharptr</i>);</b>
858     </P>
859     <P>
860     The <b>pcre_info()</b> function is now obsolete because its interface is too
861     restrictive to return all the available data about a compiled pattern. New
862     programs should use <b>pcre_fullinfo()</b> instead. The yield of
863     <b>pcre_info()</b> is the number of capturing subpatterns, or one of the
864     following negative numbers:
865     <pre>
866     PCRE_ERROR_NULL the argument <i>code</i> was NULL
867     PCRE_ERROR_BADMAGIC the "magic number" was not found
868 nigel 75 </pre>
869 nigel 63 If the <i>optptr</i> argument is not NULL, a copy of the options with which the
870     pattern was compiled is placed in the integer it points to (see
871     PCRE_INFO_OPTIONS above).
872     </P>
873     <P>
874     If the pattern is not anchored and the <i>firstcharptr</i> argument is not NULL,
875     it is used to pass back information about the first character of any matched
876     string (see PCRE_INFO_FIRSTBYTE above).
877     </P>
878 nigel 77 <br><a name="SEC12" href="#TOC1">REFERENCE COUNTS</a><br>
879 nigel 63 <P>
880 nigel 77 <b>int pcre_refcount(pcre *<i>code</i>, int <i>adjust</i>);</b>
881     </P>
882     <P>
883     The <b>pcre_refcount()</b> function is used to maintain a reference count in the
884     data block that contains a compiled pattern. It is provided for the benefit of
885     applications that operate in an object-oriented manner, where different parts
886     of the application may be using the same compiled pattern, but you want to free
887     the block when they are all done.
888     </P>
889     <P>
890     When a pattern is compiled, the reference count field is initialized to zero.
891     It is changed only by calling this function, whose action is to add the
892     <i>adjust</i> value (which may be positive or negative) to it. The yield of the
893     function is the new value. However, the value of the count is constrained to
894     lie between 0 and 65535, inclusive. If the new value is outside these limits,
895     it is forced to the appropriate limit value.
896     </P>
897     <P>
898     Except when it is zero, the reference count is not correctly preserved if a
899     pattern is compiled on one host and then transferred to a host whose byte-order
900     is different. (This seems a highly unlikely scenario.)
901     </P>
902     <br><a name="SEC13" href="#TOC1">MATCHING A PATTERN: THE TRADITIONAL FUNCTION</a><br>
903     <P>
904 nigel 63 <b>int pcre_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
905     <b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
906     <b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>);</b>
907     </P>
908     <P>
909     The function <b>pcre_exec()</b> is called to match a subject string against a
910 nigel 75 compiled pattern, which is passed in the <i>code</i> argument. If the
911 nigel 63 pattern has been studied, the result of the study should be passed in the
912 nigel 77 <i>extra</i> argument. This function is the main matching facility of the
913     library, and it operates in a Perl-like manner. For specialist use there is
914     also an alternative matching function, which is described
915     <a href="#dfamatch">below</a>
916     in the section about the <b>pcre_dfa_exec()</b> function.
917 nigel 63 </P>
918     <P>
919 nigel 75 In most applications, the pattern will have been compiled (and optionally
920     studied) in the same process that calls <b>pcre_exec()</b>. However, it is
921     possible to save compiled patterns and study data, and then use them later
922     in different processes, possibly even on different hosts. For a discussion
923     about this, see the
924     <a href="pcreprecompile.html"><b>pcreprecompile</b></a>
925     documentation.
926 nigel 63 </P>
927     <P>
928 nigel 75 Here is an example of a simple call to <b>pcre_exec()</b>:
929 nigel 63 <pre>
930     int rc;
931     int ovector[30];
932     rc = pcre_exec(
933     re, /* result of pcre_compile() */
934     NULL, /* we didn't study the pattern */
935     "some string", /* the subject string */
936     11, /* the length of the subject string */
937     0, /* start at offset 0 in the subject */
938     0, /* default options */
939 nigel 75 ovector, /* vector of integers for substring information */
940 nigel 77 30); /* number of elements (NOT size in bytes) */
941 nigel 75 <a name="extradata"></a></PRE>
942 nigel 63 </P>
943 nigel 75 <br><b>
944     Extra data for <b>pcre_exec()</b>
945     </b><br>
946 nigel 63 <P>
947     If the <i>extra</i> argument is not NULL, it must point to a <b>pcre_extra</b>
948     data block. The <b>pcre_study()</b> function returns such a block (when it
949     doesn't return NULL), but you can also create one for yourself, and pass
950 nigel 75 additional information in it. The fields in a <b>pcre_extra</b> block are as
951     follows:
952 nigel 63 <pre>
953     unsigned long int <i>flags</i>;
954     void *<i>study_data</i>;
955     unsigned long int <i>match_limit</i>;
956     void *<i>callout_data</i>;
957 nigel 75 const unsigned char *<i>tables</i>;
958     </pre>
959 nigel 63 The <i>flags</i> field is a bitmap that specifies which of the other fields
960     are set. The flag bits are:
961     <pre>
965 nigel 75 PCRE_EXTRA_TABLES
966     </pre>
967 nigel 63 Other flag bits should be set to zero. The <i>study_data</i> field is set in the
968     <b>pcre_extra</b> block that is returned by <b>pcre_study()</b>, together with
969 nigel 75 the appropriate flag bit. You should not set this yourself, but you may add to
970     the block by setting the other fields and their corresponding flag bits.
971 nigel 63 </P>
972     <P>
973     The <i>match_limit</i> field provides a means of preventing PCRE from using up a
974     vast amount of resources when running patterns that are not going to match,
975     but which have a very large number of possibilities in their search trees. The
976 nigel 75 classic example is the use of nested unlimited repeats.
977 nigel 63 </P>
978     <P>
979 nigel 75 Internally, PCRE uses a function called <b>match()</b> which it calls repeatedly
980     (sometimes recursively). The limit is imposed on the number of times this
981     function is called during a match, which has the effect of limiting the amount
982     of recursion and backtracking that can take place. For patterns that are not
983     anchored, the count starts from zero for each position in the subject string.
984     </P>
985     <P>
986 nigel 63 The default limit for the library can be set when PCRE is built; the default
987     default is 10 million, which handles all but the most extreme cases. You can
988 nigel 75 reduce the default by suppling <b>pcre_exec()</b> with a <b>pcre_extra</b> block
989 nigel 63 in which <i>match_limit</i> is set to a smaller value, and
990     PCRE_EXTRA_MATCH_LIMIT is set in the <i>flags</i> field. If the limit is
991     exceeded, <b>pcre_exec()</b> returns PCRE_ERROR_MATCHLIMIT.
992     </P>
993     <P>
994     The <i>pcre_callout</i> field is used in conjunction with the "callout" feature,
995 nigel 75 which is described in the
996     <a href="pcrecallout.html"><b>pcrecallout</b></a>
997     documentation.
998 nigel 63 </P>
999     <P>
1000 nigel 75 The <i>tables</i> field is used to pass a character tables pointer to
1001     <b>pcre_exec()</b>; this overrides the value that is stored with the compiled
1002     pattern. A non-NULL value is stored with the compiled pattern only if custom
1003     tables were supplied to <b>pcre_compile()</b> via its <i>tableptr</i> argument.
1004     If NULL is passed to <b>pcre_exec()</b> using this mechanism, it forces PCRE's
1005     internal tables to be used. This facility is helpful when re-using patterns
1006     that have been saved after compiling with an external set of tables, because
1007     the external tables might be at a different address when <b>pcre_exec()</b> is
1008     called. See the
1009     <a href="pcreprecompile.html"><b>pcreprecompile</b></a>
1010     documentation for a discussion of saving compiled patterns for later use.
1011 nigel 63 </P>
1012 nigel 75 <br><b>
1013     Option bits for <b>pcre_exec()</b>
1014     </b><br>
1015 nigel 63 <P>
1016 nigel 75 The unused bits of the <i>options</i> argument for <b>pcre_exec()</b> must be
1017     zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NOTBOL,
1019 nigel 63 <pre>
1020 nigel 75 PCRE_ANCHORED
1021     </pre>
1022     The PCRE_ANCHORED option limits <b>pcre_exec()</b> to matching at the first
1023     matching position. If a pattern was compiled with PCRE_ANCHORED, or turned out
1024     to be anchored by virtue of its contents, it cannot be made unachored at
1025     matching time.
1026     <pre>
1027 nigel 63 PCRE_NOTBOL
1028 nigel 75 </pre>
1029     This option specifies that first character of the subject string is not the
1030     beginning of a line, so the circumflex metacharacter should not match before
1031     it. Setting this without PCRE_MULTILINE (at compile time) causes circumflex
1032     never to match. This option affects only the behaviour of the circumflex
1033     metacharacter. It does not affect \A.
1034 nigel 63 <pre>
1035     PCRE_NOTEOL
1036 nigel 75 </pre>
1037     This option specifies that the end of the subject string is not the end of a
1038     line, so the dollar metacharacter should not match it nor (except in multiline
1039     mode) a newline immediately before it. Setting this without PCRE_MULTILINE (at
1040     compile time) causes dollar never to match. This option affects only the
1041     behaviour of the dollar metacharacter. It does not affect \Z or \z.
1042 nigel 63 <pre>
1044 nigel 75 </pre>
1045 nigel 63 An empty string is not considered to be a valid match if this option is set. If
1046     there are alternatives in the pattern, they are tried. If all the alternatives
1047     match the empty string, the entire match fails. For example, if the pattern
1048     <pre>
1049     a?b?
1050 nigel 75 </pre>
1051 nigel 63 is applied to a string not beginning with "a" or "b", it matches the empty
1052     string at the start of the subject. With PCRE_NOTEMPTY set, this match is not
1053     valid, so PCRE searches further into the string for occurrences of "a" or "b".
1054     </P>
1055     <P>
1056     Perl has no direct equivalent of PCRE_NOTEMPTY, but it does make a special case
1057     of a pattern match of the empty string within its <b>split()</b> function, and
1058     when using the /g modifier. It is possible to emulate Perl's behaviour after
1059     matching a null string by first trying the match again at the same offset with
1060 nigel 75 PCRE_NOTEMPTY and PCRE_ANCHORED, and then if that fails by advancing the
1061     starting offset (see below) and trying an ordinary match again. There is some
1062     code that demonstrates how to do this in the <i>pcredemo.c</i> sample program.
1063     <pre>
1065     </pre>
1066     When PCRE_UTF8 is set at compile time, the validity of the subject as a UTF-8
1067     string is automatically checked when <b>pcre_exec()</b> is subsequently called.
1068     The value of <i>startoffset</i> is also checked to ensure that it points to the
1069     start of a UTF-8 character. If an invalid UTF-8 sequence of bytes is found,
1070     <b>pcre_exec()</b> returns the error PCRE_ERROR_BADUTF8. If <i>startoffset</i>
1071     contains an invalid value, PCRE_ERROR_BADUTF8_OFFSET is returned.
1072 nigel 63 </P>
1073     <P>
1074 nigel 75 If you already know that your subject is valid, and you want to skip these
1075     checks for performance reasons, you can set the PCRE_NO_UTF8_CHECK option when
1076     calling <b>pcre_exec()</b>. You might want to do this for the second and
1077     subsequent calls to <b>pcre_exec()</b> if you are making repeated calls to find
1078     all the matches in a single subject string. However, you should be sure that
1079     the value of <i>startoffset</i> points to the start of a UTF-8 character. When
1080     PCRE_NO_UTF8_CHECK is set, the effect of passing an invalid UTF-8 string as a
1081     subject, or a value of <i>startoffset</i> that does not point to the start of a
1082     UTF-8 character, is undefined. Your program may crash.
1083     <pre>
1085     </pre>
1086     This option turns on the partial matching feature. If the subject string fails
1087     to match the pattern, but at some point during the matching process the end of
1088     the subject was reached (that is, the subject partially matches the pattern and
1089     the failure to match occurred only because there were not enough subject
1090     characters), <b>pcre_exec()</b> returns PCRE_ERROR_PARTIAL instead of
1091     PCRE_ERROR_NOMATCH. When PCRE_PARTIAL is used, there are restrictions on what
1092     may appear in the pattern. These are discussed in the
1093     <a href="pcrepartial.html"><b>pcrepartial</b></a>
1094     documentation.
1095     </P>
1096     <br><b>
1097     The string to be matched by <b>pcre_exec()</b>
1098     </b><br>
1099     <P>
1100 nigel 63 The subject string is passed to <b>pcre_exec()</b> as a pointer in
1101 nigel 73 <i>subject</i>, a length in <i>length</i>, and a starting byte offset in
1102 nigel 75 <i>startoffset</i>. In UTF-8 mode, the byte offset must point to the start of a
1103     UTF-8 character. Unlike the pattern string, the subject may contain binary zero
1104     bytes. When the starting offset is zero, the search for a match starts at the
1105     beginning of the subject, and this is by far the most common case.
1106 nigel 63 </P>
1107     <P>
1108     A non-zero starting offset is useful when searching for another match in the
1109     same subject by calling <b>pcre_exec()</b> again after a previous success.
1110     Setting <i>startoffset</i> differs from just passing over a shortened string and
1111     setting PCRE_NOTBOL in the case of a pattern that begins with any kind of
1112     lookbehind. For example, consider the pattern
1113     <pre>
1114     \Biss\B
1115 nigel 75 </pre>
1116 nigel 63 which finds occurrences of "iss" in the middle of words. (\B matches only if
1117     the current position in the subject is not a word boundary.) When applied to
1118     the string "Mississipi" the first call to <b>pcre_exec()</b> finds the first
1119     occurrence. If <b>pcre_exec()</b> is called again with just the remainder of the
1120     subject, namely "issipi", it does not match, because \B is always false at the
1121     start of the subject, which is deemed to be a word boundary. However, if
1122     <b>pcre_exec()</b> is passed the entire string again, but with <i>startoffset</i>
1123     set to 4, it finds the second occurrence of "iss" because it is able to look
1124     behind the starting point to discover that it is preceded by a letter.
1125     </P>
1126     <P>
1127     If a non-zero starting offset is passed when the pattern is anchored, one
1128 nigel 75 attempt to match at the given offset is made. This can only succeed if the
1129 nigel 63 pattern does not require the match to be at the start of the subject.
1130     </P>
1131 nigel 75 <br><b>
1132     How <b>pcre_exec()</b> returns captured substrings
1133     </b><br>
1134 nigel 63 <P>
1135     In general, a pattern matches a certain portion of the subject, and in
1136     addition, further substrings from the subject may be picked out by parts of the
1137     pattern. Following the usage in Jeffrey Friedl's book, this is called
1138     "capturing" in what follows, and the phrase "capturing subpattern" is used for
1139     a fragment of a pattern that picks out a substring. PCRE supports several other
1140     kinds of parenthesized subpattern that do not cause substrings to be captured.
1141     </P>
1142     <P>
1143     Captured substrings are returned to the caller via a vector of integer offsets
1144     whose address is passed in <i>ovector</i>. The number of elements in the vector
1145 nigel 75 is passed in <i>ovecsize</i>, which must be a non-negative number. <b>Note</b>:
1146     this argument is NOT the size of <i>ovector</i> in bytes.
1147 nigel 63 </P>
1148     <P>
1149 nigel 75 The first two-thirds of the vector is used to pass back captured substrings,
1150     each substring using a pair of integers. The remaining third of the vector is
1151     used as workspace by <b>pcre_exec()</b> while matching capturing subpatterns,
1152     and is not available for passing back information. The length passed in
1153     <i>ovecsize</i> should always be a multiple of three. If it is not, it is
1154     rounded down.
1155     </P>
1156     <P>
1157     When a match is successful, information about captured substrings is returned
1158     in pairs of integers, starting at the beginning of <i>ovector</i>, and
1159 nigel 63 continuing up to two-thirds of its length at the most. The first element of a
1160     pair is set to the offset of the first character in a substring, and the second
1161     is set to the offset of the first character after the end of a substring. The
1162     first pair, <i>ovector[0]</i> and <i>ovector[1]</i>, identify the portion of the
1163     subject string matched by the entire pattern. The next pair is used for the
1164     first capturing subpattern, and so on. The value returned by <b>pcre_exec()</b>
1165     is the number of pairs that have been set. If there are no capturing
1166     subpatterns, the return value from a successful match is 1, indicating that
1167     just the first pair of offsets has been set.
1168     </P>
1169     <P>
1170     Some convenience functions are provided for extracting the captured substrings
1171     as separate strings. These are described in the following section.
1172     </P>
1173     <P>
1174     It is possible for an capturing subpattern number <i>n+1</i> to match some
1175     part of the subject when subpattern <i>n</i> has not been used at all. For
1176     example, if the string "abc" is matched against the pattern (a|(z))(bc)
1177     subpatterns 1 and 3 are matched, but 2 is not. When this happens, both offset
1178     values corresponding to the unused subpattern are set to -1.
1179     </P>
1180     <P>
1181     If a capturing subpattern is matched repeatedly, it is the last portion of the
1182 nigel 75 string that it matched that is returned.
1183 nigel 63 </P>
1184     <P>
1185 nigel 75 If the vector is too small to hold all the captured substring offsets, it is
1186     used as far as possible (up to two-thirds of its length), and the function
1187     returns a value of zero. In particular, if the substring offsets are not of
1188     interest, <b>pcre_exec()</b> may be called with <i>ovector</i> passed as NULL and
1189 nigel 63 <i>ovecsize</i> as zero. However, if the pattern contains back references and
1190 nigel 75 the <i>ovector</i> is not big enough to remember the related substrings, PCRE
1191     has to get additional memory for use during matching. Thus it is usually
1192     advisable to supply an <i>ovector</i>.
1193 nigel 63 </P>
1194     <P>
1195     Note that <b>pcre_info()</b> can be used to find out how many capturing
1196     subpatterns there are in a compiled pattern. The smallest size for
1197     <i>ovector</i> that will allow for <i>n</i> captured substrings, in addition to
1198     the offsets of the substring matched by the whole pattern, is (<i>n</i>+1)*3.
1199 nigel 77 <a name="errorlist"></a></P>
1200 nigel 75 <br><b>
1201     Return values from <b>pcre_exec()</b>
1202     </b><br>
1203 nigel 63 <P>
1204     If <b>pcre_exec()</b> fails, it returns a negative number. The following are
1205     defined in the header file:
1206     <pre>
1207     PCRE_ERROR_NOMATCH (-1)
1208 nigel 75 </pre>
1209 nigel 63 The subject string did not match the pattern.
1210     <pre>
1211     PCRE_ERROR_NULL (-2)
1212 nigel 75 </pre>
1213 nigel 63 Either <i>code</i> or <i>subject</i> was passed as NULL, or <i>ovector</i> was
1214     NULL and <i>ovecsize</i> was not zero.
1215     <pre>
1217 nigel 75 </pre>
1218 nigel 63 An unrecognized bit was set in the <i>options</i> argument.
1219     <pre>
1221 nigel 75 </pre>
1222 nigel 63 PCRE stores a 4-byte "magic number" at the start of the compiled code, to catch
1223 nigel 75 the case when it is passed a junk pointer and to detect when a pattern that was
1224     compiled in an environment of one endianness is run in an environment with the
1225     other endianness. This is the error that PCRE gives when the magic number is
1226     not present.
1227 nigel 63 <pre>
1229 nigel 75 </pre>
1230 nigel 63 While running the pattern match, an unknown item was encountered in the
1231     compiled pattern. This error could be caused by a bug in PCRE or by overwriting
1232     of the compiled pattern.
1233     <pre>
1235 nigel 75 </pre>
1236 nigel 63 If a pattern contains back references, but the <i>ovector</i> that is passed to
1237     <b>pcre_exec()</b> is not big enough to remember the referenced substrings, PCRE
1238     gets a block of memory at the start of matching to use for this purpose. If the
1239 nigel 75 call via <b>pcre_malloc()</b> fails, this error is given. The memory is
1240     automatically freed at the end of matching.
1241 nigel 63 <pre>
1243 nigel 75 </pre>
1244 nigel 63 This error is used by the <b>pcre_copy_substring()</b>,
1245     <b>pcre_get_substring()</b>, and <b>pcre_get_substring_list()</b> functions (see
1246     below). It is never returned by <b>pcre_exec()</b>.
1247     <pre>
1249 nigel 75 </pre>
1250 nigel 63 The recursion and backtracking limit, as specified by the <i>match_limit</i>
1251     field in a <b>pcre_extra</b> structure (or defaulted) was reached. See the
1252     description above.
1253     <pre>
1254     PCRE_ERROR_CALLOUT (-9)
1255 nigel 75 </pre>
1256 nigel 63 This error is never generated by <b>pcre_exec()</b> itself. It is provided for
1257     use by callout functions that want to yield a distinctive error code. See the
1258 nigel 75 <a href="pcrecallout.html"><b>pcrecallout</b></a>
1259     documentation for details.
1260 nigel 71 <pre>
1261 nigel 73 PCRE_ERROR_BADUTF8 (-10)
1262 nigel 75 </pre>
1263 nigel 71 A string that contains an invalid UTF-8 byte sequence was passed as a subject.
1264 nigel 73 <pre>
1266 nigel 75 </pre>
1267 nigel 73 The UTF-8 byte sequence that was passed as a subject was valid, but the value
1268     of <i>startoffset</i> did not point to the beginning of a UTF-8 character.
1269 nigel 75 <pre>
1270 nigel 77 PCRE_ERROR_PARTIAL (-12)
1271 nigel 75 </pre>
1272     The subject string did not match, but it did match partially. See the
1273     <a href="pcrepartial.html"><b>pcrepartial</b></a>
1274     documentation for details of partial matching.
1275     <pre>
1276 nigel 77 PCRE_ERROR_BADPARTIAL (-13)
1277 nigel 75 </pre>
1278     The PCRE_PARTIAL option was used with a compiled pattern containing items that
1279     are not supported for partial matching. See the
1280     <a href="pcrepartial.html"><b>pcrepartial</b></a>
1281     documentation for details of partial matching.
1282     <pre>
1283 nigel 77 PCRE_ERROR_INTERNAL (-14)
1284 nigel 75 </pre>
1285     An unexpected internal error has occurred. This error could be caused by a bug
1286     in PCRE or by overwriting of the compiled pattern.
1287     <pre>
1288 nigel 77 PCRE_ERROR_BADCOUNT (-15)
1289 nigel 75 </pre>
1290     This error is given if the value of the <i>ovecsize</i> argument is negative.
1291 nigel 73 </P>
1292 nigel 77 <br><a name="SEC14" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a><br>
1293 nigel 63 <P>
1294     <b>int pcre_copy_substring(const char *<i>subject</i>, int *<i>ovector</i>,</b>
1295     <b>int <i>stringcount</i>, int <i>stringnumber</i>, char *<i>buffer</i>,</b>
1296     <b>int <i>buffersize</i>);</b>
1297     </P>
1298     <P>
1299     <b>int pcre_get_substring(const char *<i>subject</i>, int *<i>ovector</i>,</b>
1300     <b>int <i>stringcount</i>, int <i>stringnumber</i>,</b>
1301     <b>const char **<i>stringptr</i>);</b>
1302     </P>
1303     <P>
1304     <b>int pcre_get_substring_list(const char *<i>subject</i>,</b>
1305     <b>int *<i>ovector</i>, int <i>stringcount</i>, const char ***<i>listptr</i>);</b>
1306     </P>
1307     <P>
1308     Captured substrings can be accessed directly by using the offsets returned by
1309     <b>pcre_exec()</b> in <i>ovector</i>. For convenience, the functions
1310     <b>pcre_copy_substring()</b>, <b>pcre_get_substring()</b>, and
1311     <b>pcre_get_substring_list()</b> are provided for extracting captured substrings
1312     as new, separate, zero-terminated strings. These functions identify substrings
1313     by number. The next section describes functions for extracting named
1314     substrings. A substring that contains a binary zero is correctly extracted and
1315     has a further zero added on the end, but the result is not, of course,
1316     a C string.
1317     </P>
1318     <P>
1319     The first three arguments are the same for all three of these functions:
1320 nigel 75 <i>subject</i> is the subject string that has just been successfully matched,
1321 nigel 63 <i>ovector</i> is a pointer to the vector of integer offsets that was passed to
1322     <b>pcre_exec()</b>, and <i>stringcount</i> is the number of substrings that were
1323     captured by the match, including the substring that matched the entire regular
1324 nigel 75 expression. This is the value returned by <b>pcre_exec()</b> if it is greater
1325     than zero. If <b>pcre_exec()</b> returned zero, indicating that it ran out of
1326     space in <i>ovector</i>, the value passed as <i>stringcount</i> should be the
1327     number of elements in the vector divided by three.
1328 nigel 63 </P>
1329     <P>
1330     The functions <b>pcre_copy_substring()</b> and <b>pcre_get_substring()</b>
1331     extract a single substring, whose number is given as <i>stringnumber</i>. A
1332 nigel 75 value of zero extracts the substring that matched the entire pattern, whereas
1333 nigel 63 higher values extract the captured substrings. For <b>pcre_copy_substring()</b>,
1334     the string is placed in <i>buffer</i>, whose length is given by
1335     <i>buffersize</i>, while for <b>pcre_get_substring()</b> a new block of memory is
1336     obtained via <b>pcre_malloc</b>, and its address is returned via
1337     <i>stringptr</i>. The yield of the function is the length of the string, not
1338     including the terminating zero, or one of
1339     <pre>
1341 nigel 75 </pre>
1342 nigel 63 The buffer was too small for <b>pcre_copy_substring()</b>, or the attempt to get
1343     memory failed for <b>pcre_get_substring()</b>.
1344     <pre>
1346 nigel 75 </pre>
1347 nigel 63 There is no substring whose number is <i>stringnumber</i>.
1348     </P>
1349     <P>
1350     The <b>pcre_get_substring_list()</b> function extracts all available substrings
1351     and builds a list of pointers to them. All this is done in a single block of
1352 nigel 75 memory that is obtained via <b>pcre_malloc</b>. The address of the memory block
1353 nigel 63 is returned via <i>listptr</i>, which is also the start of the list of string
1354     pointers. The end of the list is marked by a NULL pointer. The yield of the
1355     function is zero if all went well, or
1356     <pre>
1358 nigel 75 </pre>
1359 nigel 63 if the attempt to get the memory block failed.
1360     </P>
1361     <P>
1362     When any of these functions encounter a substring that is unset, which can
1363     happen when capturing subpattern number <i>n+1</i> matches some part of the
1364     subject, but subpattern <i>n</i> has not been used at all, they return an empty
1365     string. This can be distinguished from a genuine zero-length substring by
1366     inspecting the appropriate offset in <i>ovector</i>, which is negative for unset
1367     substrings.
1368     </P>
1369     <P>
1370     The two convenience functions <b>pcre_free_substring()</b> and
1371     <b>pcre_free_substring_list()</b> can be used to free the memory returned by
1372     a previous call of <b>pcre_get_substring()</b> or
1373     <b>pcre_get_substring_list()</b>, respectively. They do nothing more than call
1374     the function pointed to by <b>pcre_free</b>, which of course could be called
1375     directly from a C program. However, PCRE is used in some situations where it is
1376     linked via a special interface to another programming language which cannot use
1377     <b>pcre_free</b> directly; it is for these cases that the functions are
1378     provided.
1379     </P>
1380 nigel 77 <br><a name="SEC15" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a><br>
1381 nigel 63 <P>
1382 nigel 75 <b>int pcre_get_stringnumber(const pcre *<i>code</i>,</b>
1383     <b>const char *<i>name</i>);</b>
1384     </P>
1385     <P>
1386 nigel 63 <b>int pcre_copy_named_substring(const pcre *<i>code</i>,</b>
1387     <b>const char *<i>subject</i>, int *<i>ovector</i>,</b>
1388     <b>int <i>stringcount</i>, const char *<i>stringname</i>,</b>
1389     <b>char *<i>buffer</i>, int <i>buffersize</i>);</b>
1390     </P>
1391     <P>
1392     <b>int pcre_get_named_substring(const pcre *<i>code</i>,</b>
1393     <b>const char *<i>subject</i>, int *<i>ovector</i>,</b>
1394     <b>int <i>stringcount</i>, const char *<i>stringname</i>,</b>
1395     <b>const char **<i>stringptr</i>);</b>
1396     </P>
1397     <P>
1398 nigel 75 To extract a substring by name, you first have to find associated number.
1399     For example, for this pattern
1400 nigel 63 <pre>
1401 nigel 75 (a+)b(?&#60;xxx&#62;\d+)...
1402     </pre>
1403     the number of the subpattern called "xxx" is 2. You can find the number from
1404     the name by calling <b>pcre_get_stringnumber()</b>. The first argument is the
1405     compiled pattern, and the second is the name. The yield of the function is the
1406     subpattern number, or PCRE_ERROR_NOSUBSTRING (-7) if there is no subpattern of
1407     that name.
1408 nigel 63 </P>
1409     <P>
1410 nigel 75 Given the number, you can extract the substring directly, or use one of the
1411     functions described in the previous section. For convenience, there are also
1412     two functions that do the whole job.
1413 nigel 63 </P>
1414     <P>
1415     Most of the arguments of <i>pcre_copy_named_substring()</i> and
1416 nigel 75 <i>pcre_get_named_substring()</i> are the same as those for the similarly named
1417     functions that extract by number. As these are described in the previous
1418     section, they are not re-described here. There are just two differences:
1419 nigel 63 </P>
1420     <P>
1421     First, instead of a substring number, a substring name is given. Second, there
1422     is an extra argument, given at the start, which is a pointer to the compiled
1423     pattern. This is needed in order to gain access to the name-to-number
1424     translation table.
1425     </P>
1426     <P>
1427     These functions call <b>pcre_get_stringnumber()</b>, and if it succeeds, they
1428     then call <i>pcre_copy_substring()</i> or <i>pcre_get_substring()</i>, as
1429     appropriate.
1430     </P>
1431 nigel 77 <br><a name="SEC16" href="#TOC1">FINDING ALL POSSIBLE MATCHES</a><br>
1432 nigel 63 <P>
1433 nigel 77 The traditional matching function uses a similar algorithm to Perl, which stops
1434     when it finds the first match, starting at a given point in the subject. If you
1435     want to find all possible matches, or the longest possible match, consider
1436     using the alternative matching function (see below) instead. If you cannot use
1437     the alternative function, but still need to find all possible matches, you
1438     can kludge it up by making use of the callout facility, which is described in
1439     the
1440     <a href="pcrecallout.html"><b>pcrecallout</b></a>
1441     documentation.
1442     </P>
1443     <P>
1444     What you have to do is to insert a callout right at the end of the pattern.
1445     When your callout function is called, extract and save the current matched
1446     substring. Then return 1, which forces <b>pcre_exec()</b> to backtrack and try
1447     other alternatives. Ultimately, when it runs out of matches, <b>pcre_exec()</b>
1448     will yield PCRE_ERROR_NOMATCH.
1449     <a name="dfamatch"></a></P>
1450     <br><a name="SEC17" href="#TOC1">MATCHING A PATTERN: THE ALTERNATIVE FUNCTION</a><br>
1451     <P>
1452     <b>int pcre_dfa_exec(const pcre *<i>code</i>, const pcre_extra *<i>extra</i>,</b>
1453     <b>const char *<i>subject</i>, int <i>length</i>, int <i>startoffset</i>,</b>
1454     <b>int <i>options</i>, int *<i>ovector</i>, int <i>ovecsize</i>,</b>
1455     <b>int *<i>workspace</i>, int <i>wscount</i>);</b>
1456     </P>
1457     <P>
1458     The function <b>pcre_dfa_exec()</b> is called to match a subject string against
1459     a compiled pattern, using a "DFA" matching algorithm. This has different
1460     characteristics to the normal algorithm, and is not compatible with Perl. Some
1461     of the features of PCRE patterns are not supported. Nevertheless, there are
1462     times when this kind of matching can be useful. For a discussion of the two
1463     matching algorithms, see the
1464     <a href="pcrematching.html"><b>pcrematching</b></a>
1465     documentation.
1466     </P>
1467     <P>
1468     The arguments for the <b>pcre_dfa_exec()</b> function are the same as for
1469     <b>pcre_exec()</b>, plus two extras. The <i>ovector</i> argument is used in a
1470     different way, and this is described below. The other common arguments are used
1471     in the same way as for <b>pcre_exec()</b>, so their description is not repeated
1472     here.
1473     </P>
1474     <P>
1475     The two additional arguments provide workspace for the function. The workspace
1476     vector should contain at least 20 elements. It is used for keeping track of
1477     multiple paths through the pattern tree. More workspace will be needed for
1478     patterns and subjects where there are a lot of possible matches.
1479     </P>
1480     <P>
1481     Here is an example of a simple call to <b>pcre_exec()</b>:
1482     <pre>
1483     int rc;
1484     int ovector[10];
1485     int wspace[20];
1486     rc = pcre_exec(
1487     re, /* result of pcre_compile() */
1488     NULL, /* we didn't study the pattern */
1489     "some string", /* the subject string */
1490     11, /* the length of the subject string */
1491     0, /* start at offset 0 in the subject */
1492     0, /* default options */
1493     ovector, /* vector of integers for substring information */
1494     10, /* number of elements (NOT size in bytes) */
1495     wspace, /* working space vector */
1496     20); /* number of elements (NOT size in bytes) */
1497     </PRE>
1498     </P>
1499     <br><b>
1500     Option bits for <b>pcre_dfa_exec()</b>
1501     </b><br>
1502     <P>
1503     The unused bits of the <i>options</i> argument for <b>pcre_dfa_exec()</b> must be
1504     zero. The only bits that may be set are PCRE_ANCHORED, PCRE_NOTBOL,
1506     PCRE_DFA_SHORTEST, and PCRE_DFA_RESTART. All but the last three of these are
1507     the same as for <b>pcre_exec()</b>, so their description is not repeated here.
1508     <pre>
1510     </pre>
1511     This has the same general effect as it does for <b>pcre_exec()</b>, but the
1512     details are slightly different. When PCRE_PARTIAL is set for
1513     <b>pcre_dfa_exec()</b>, the return code PCRE_ERROR_NOMATCH is converted into
1514     PCRE_ERROR_PARTIAL if the end of the subject is reached, there have been no
1515     complete matches, but there is still at least one matching possibility. The
1516     portion of the string that provided the partial match is set as the first
1517     matching string.
1518     <pre>
1520     </pre>
1521     Setting the PCRE_DFA_SHORTEST option causes the matching algorithm to stop as
1522     soon as it has found one match. Because of the way the DFA algorithm works,
1523     this is necessarily the shortest possible match at the first possible matching
1524     point in the subject string.
1525     <pre>
1527     </pre>
1528     When <b>pcre_dfa_exec()</b> is called with the PCRE_PARTIAL option, and returns
1529     a partial match, it is possible to call it again, with additional subject
1530     characters, and have it continue with the same match. The PCRE_DFA_RESTART
1531     option requests this action; when it is set, the <i>workspace</i> and
1532     <i>wscount</i> options must reference the same vector as before because data
1533     about the match so far is left in them after a partial match. There is more
1534     discussion of this facility in the
1535     <a href="pcrepartial.html"><b>pcrepartial</b></a>
1536     documentation.
1537     </P>
1538     <br><b>
1539     Successful returns from <b>pcre_dfa_exec()</b>
1540     </b><br>
1541     <P>
1542     When <b>pcre_dfa_exec()</b> succeeds, it may have matched more than one
1543     substring in the subject. Note, however, that all the matches from one run of
1544     the function start at the same point in the subject. The shorter matches are
1545     all initial substrings of the longer matches. For example, if the pattern
1546     <pre>
1547     &#60;.*&#62;
1548     </pre>
1549     is matched against the string
1550     <pre>
1551     This is &#60;something&#62; &#60;something else&#62; &#60;something further&#62; no more
1552     </pre>
1553     the three matched strings are
1554     <pre>
1555     &#60;something&#62;
1556     &#60;something&#62; &#60;something else&#62;
1557     &#60;something&#62; &#60;something else&#62; &#60;something further&#62;
1558     </pre>
1559     On success, the yield of the function is a number greater than zero, which is
1560     the number of matched substrings. The substrings themselves are returned in
1561     <i>ovector</i>. Each string uses two elements; the first is the offset to the
1562     start, and the second is the offset to the end. All the strings have the same
1563     start offset. (Space could have been saved by giving this only once, but it was
1564     decided to retain some compatibility with the way <b>pcre_exec()</b> returns
1565     data, even though the meaning of the strings is different.)
1566     </P>
1567     <P>
1568     The strings are returned in reverse order of length; that is, the longest
1569     matching string is given first. If there were too many matches to fit into
1570     <i>ovector</i>, the yield of the function is zero, and the vector is filled with
1571     the longest matches.
1572     </P>
1573     <br><b>
1574     Error returns from <b>pcre_dfa_exec()</b>
1575     </b><br>
1576     <P>
1577     The <b>pcre_dfa_exec()</b> function returns a negative number when it fails.
1578     Many of the errors are the same as for <b>pcre_exec()</b>, and these are
1579     described
1580     <a href="#errorlist">above.</a>
1581     There are in addition the following errors that are specific to
1582     <b>pcre_dfa_exec()</b>:
1583     <pre>
1584     PCRE_ERROR_DFA_UITEM (-16)
1585     </pre>
1586     This return is given if <b>pcre_dfa_exec()</b> encounters an item in the pattern
1587     that it does not support, for instance, the use of \C or a back reference.
1588     <pre>
1589     PCRE_ERROR_DFA_UCOND (-17)
1590     </pre>
1591     This return is given if <b>pcre_dfa_exec()</b> encounters a condition item in a
1592     pattern that uses a back reference for the condition. This is not supported.
1593     <pre>
1595     </pre>
1596     This return is given if <b>pcre_dfa_exec()</b> is called with an <i>extra</i>
1597     block that contains a setting of the <i>match_limit</i> field. This is not
1598     supported (it is meaningless).
1599     <pre>
1600     PCRE_ERROR_DFA_WSSIZE (-19)
1601     </pre>
1602     This return is given if <b>pcre_dfa_exec()</b> runs out of space in the
1603     <i>workspace</i> vector.
1604     <pre>
1606     </pre>
1607     When a recursive subpattern is processed, the matching function calls itself
1608     recursively, using private vectors for <i>ovector</i> and <i>workspace</i>. This
1609     error is given if the output vector is not large enough. This should be
1610     extremely rare, as a vector of size 1000 is used.
1611     </P>
1612     <P>
1613     Last updated: 16 May 2005
1614 nigel 63 <br>
1615 nigel 77 Copyright &copy; 1997-2005 University of Cambridge.
1616 nigel 75 <p>
1617     Return to the <a href="index.html">PCRE index page</a>.
1618     </p>

ViewVC Help
Powered by ViewVC 1.1.12