ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 79 - (show annotations)
Sat Feb 24 21:40:52 2007 UTC (14 years, 1 month ago) by nigel
File MIME type: text/html
File size: 72055 byte(s)
Error occurred while calculating annotation data.
Load pcre-6.1 into code/trunk.
1 <html>
2 <head>
3 <title>pcreapi specification</title>
4 </head>
5 <body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
6 <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 <ul>
16 <li><a name="TOC1" href="#SEC1">PCRE NATIVE API</a>
17 <li><a name="TOC2" href="#SEC2">PCRE API OVERVIEW</a>
18 <li><a name="TOC3" href="#SEC3">MULTITHREADING</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 <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>
31 <li><a name="TOC16" href="#SEC16">FINDING ALL POSSIBLE MATCHES</a>
33 </ul>
34 <br><a name="SEC1" href="#TOC1">PCRE NATIVE API</a><br>
35 <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 <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 <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 <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 <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 <b>int pcre_refcount(pcre *<i>code</i>, int <i>adjust</i>);</b>
113 </P>
114 <P>
115 <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 <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 <b>int (*pcre_callout)(pcre_callout_block *);</b>
134 </P>
135 <br><a name="SEC2" href="#TOC1">PCRE API OVERVIEW</a><br>
136 <P>
137 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 <a href="pcreposix.html"><b>pcreposix</b></a>
141 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 </P>
146 <P>
147 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 Applications can use these to include support for different releases of PCRE.
153 </P>
154 <P>
155 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 <a href="pcresample.html"><b>pcresample</b></a>
161 documentation describes how to run it.
162 </P>
163 <P>
164 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 In addition to the main compiling and matching functions, there are convenience
175 functions for extracting captured substrings from a subject string that is
176 matched by <b>pcre_exec()</b>. They are:
177 <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 <b>pcre_get_stringnumber()</b>
184 </pre>
185 <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 The function <b>pcre_maketables()</b> is used to build a set of character tables
190 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 </P>
195 <P>
196 The function <b>pcre_fullinfo()</b> is used to find out information about a
197 compiled pattern; <b>pcre_info()</b> is an obsolete version that returns only
198 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 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 The global variables <b>pcre_malloc</b> and <b>pcre_free</b> initially contain
209 the entry points of the standard <b>malloc()</b> and <b>free()</b> functions,
210 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 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 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 </P>
226 <P>
227 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 points during a matching operation. Details are given in the
230 <a href="pcrecallout.html"><b>pcrecallout</b></a>
231 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 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 </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 <br><a name="SEC4" href="#TOC1">SAVING PRECOMPILED PATTERNS FOR LATER USE</a><br>
245 <P>
246 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 <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 </pre>
269 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 </pre>
279 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 </pre>
285 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 </pre>
293 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 the
296 <a href="pcreposix.html"><b>pcreposix</b></a>
297 documentation.
298 <pre>
300 </pre>
301 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 <pre>
306 </pre>
307 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 </P>
315 <br><a name="SEC6" href="#TOC1">COMPILING A PATTERN</a><br>
316 <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 <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 </P>
325 <P>
326 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 </P>
331 <P>
332 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 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 fully relocatable, because it may contain a copy of the <i>tableptr</i>
343 argument, which is an address (see below).
344 </P>
345 <P>
346 The <i>options</i> argument contains independent bits that affect the
347 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 </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 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 If the final argument, <i>tableptr</i>, is NULL, PCRE uses a default set of
373 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 </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 </pre>
392 The following names for option bits are defined in the <b>pcre.h</b> header
393 file:
394 <pre>
396 </pre>
397 If this bit is set, the pattern is forced to be "anchored", that is, it is
398 constrained to match only at the first matching point in the string that is
399 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>
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>
412 </pre>
413 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 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 <pre>
424 </pre>
425 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 </pre>
434 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 </pre>
442 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>
456 </pre>
457 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>
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>
473 </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 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 </pre>
491 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 </pre>
499 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>
504 </pre>
505 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 available only when PCRE is built to include UTF-8 support. If not, the use
508 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 <pre>
516 </pre>
517 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 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 </P>
527 <br><a name="SEC7" href="#TOC1">COMPILATION ERROR CODES</a><br>
528 <P>
529 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 <b>const char **<i>errptr</i>);</b>
587 </P>
588 <P>
589 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 function <b>pcre_study()</b> takes a pointer to a compiled pattern as its first
592 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 </P>
597 <P>
598 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 fields that can be set by the caller before the block is passed; these are
601 described
602 <a href="#extradata">below</a>
603 in the section on matching a pattern.
604 </P>
605 <P>
606 If studying the pattern does not produce any additional information
607 <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 </P>
611 <P>
612 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 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 </pre>
631 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 bytes is created.
634 <a name="localesupport"></a></P>
635 <br><a name="SEC9" href="#TOC1">LOCALE SUPPORT</a><br>
636 <P>
637 PCRE handles caseless matching, and determines whether characters are letters
638 digits, or whatever, by reference to a set of tables, indexed by character
639 value. When running in UTF-8 mode, this applies only to characters with codes
640 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 support.
643 </P>
644 <P>
645 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 </P>
652 <P>
653 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 <pre>
660 setlocale(LC_CTYPE, "fr_FR");
661 tables = pcre_maketables();
662 re = pcre_compile(..., tables);
663 </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 </P>
669 <P>
670 The pointer that is passed to <b>pcre_compile()</b> is saved with the compiled
671 pattern, and the same tables are used via this pointer by <b>pcre_study()</b>
672 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 </P>
676 <P>
677 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 <br><a name="SEC10" href="#TOC1">INFORMATION ABOUT A PATTERN</a><br>
684 <P>
685 <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 </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 <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 </pre>
718 The possible values for the third argument are defined in <b>pcre.h</b>, and are
719 as follows:
720 <pre>
722 </pre>
723 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 </pre>
729 Return the number of capturing subpatterns in the pattern. The fourth argument
730 should point to an <b>int</b> variable.
731 <pre>
733 </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 </pre>
742 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 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 (a) the pattern was compiled with the PCRE_MULTILINE option, and every branch
753 starts with "^", or
754 <br>
755 <br>
756 (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 <br>
759 <br>
760 -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 </pre>
766 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 </pre>
773 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 <pre>
784 </pre>
785 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 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 </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 (?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 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 bytes shows in hexadecimal, and undefined bytes shown as ??:
810 <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 </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 <pre>
821 </pre>
822 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 .* if PCRE_DOTALL is set and there are no back references to the subpattern in which .* appears
835 </pre>
836 For such patterns, the PCRE_ANCHORED bit is set in the options returned by
837 <b>pcre_fullinfo()</b>.
838 <pre>
840 </pre>
841 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 </pre>
848 Return the size of the data block pointed to by the <i>study_data</i> field in
849 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 <br><a name="SEC11" href="#TOC1">OBSOLETE INFO FUNCTION</a><br>
855 <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 </pre>
869 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
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 <br><a name="SEC12" href="#TOC1">REFERENCE COUNTS</a><br>
879 <P>
880 <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 <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 compiled pattern, which is passed in the <i>code</i> argument. If the
911 pattern has been studied, the result of the study should be passed in the
912 <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 </P>
918 <P>
919 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 </P>
927 <P>
928 Here is an example of a simple call to <b>pcre_exec()</b>:
929 <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 ovector, /* vector of integers for substring information */
940 30); /* number of elements (NOT size in bytes) */
941 <a name="extradata"></a></PRE>
942 </P>
943 <br><b>
944 Extra data for <b>pcre_exec()</b>
945 </b><br>
946 <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 additional information in it. The fields in a <b>pcre_extra</b> block are as
951 follows:
952 <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 const unsigned char *<i>tables</i>;
958 </pre>
959 The <i>flags</i> field is a bitmap that specifies which of the other fields
960 are set. The flag bits are:
961 <pre>
966 </pre>
967 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 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 </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 classic example is the use of nested unlimited repeats.
977 </P>
978 <P>
979 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 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 reduce the default by suppling <b>pcre_exec()</b> with a <b>pcre_extra</b> block
989 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 which is described in the
996 <a href="pcrecallout.html"><b>pcrecallout</b></a>
997 documentation.
998 </P>
999 <P>
1000 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 </P>
1012 <br><b>
1013 Option bits for <b>pcre_exec()</b>
1014 </b><br>
1015 <P>
1016 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 <pre>
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>
1028 </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 <pre>
1036 </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 <pre>
1044 </pre>
1045 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 </pre>
1051 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 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 </P>
1073 <P>
1074 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 The subject string is passed to <b>pcre_exec()</b> as a pointer in
1101 <i>subject</i>, a length in <i>length</i>, and a starting byte offset in
1102 <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 </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 </pre>
1116 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 attempt to match at the given offset is made. This can only succeed if the
1129 pattern does not require the match to be at the start of the subject.
1130 </P>
1131 <br><b>
1132 How <b>pcre_exec()</b> returns captured substrings
1133 </b><br>
1134 <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 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 </P>
1148 <P>
1149 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 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 string that it matched that is returned.
1183 </P>
1184 <P>
1185 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 <i>ovecsize</i> as zero. However, if the pattern contains back references and
1190 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 </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 <a name="errorlist"></a></P>
1200 <br><b>
1201 Return values from <b>pcre_exec()</b>
1202 </b><br>
1203 <P>
1204 If <b>pcre_exec()</b> fails, it returns a negative number. The following are
1205 defined in the header file:
1206 <pre>
1208 </pre>
1209 The subject string did not match the pattern.
1210 <pre>
1212 </pre>
1213 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 </pre>
1218 An unrecognized bit was set in the <i>options</i> argument.
1219 <pre>
1221 </pre>
1222 PCRE stores a 4-byte "magic number" at the start of the compiled code, to catch
1223 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 <pre>
1229 </pre>
1230 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 </pre>
1236 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 call via <b>pcre_malloc()</b> fails, this error is given. The memory is
1240 automatically freed at the end of matching.
1241 <pre>
1243 </pre>
1244 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 </pre>
1250 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>
1255 </pre>
1256 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 <a href="pcrecallout.html"><b>pcrecallout</b></a>
1259 documentation for details.
1260 <pre>
1262 </pre>
1263 A string that contains an invalid UTF-8 byte sequence was passed as a subject.
1264 <pre>
1266 </pre>
1267 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 <pre>
1271 </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>
1277 </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>
1284 </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>
1289 </pre>
1290 This error is given if the value of the <i>ovecsize</i> argument is negative.
1291 </P>
1292 <br><a name="SEC14" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NUMBER</a><br>
1293 <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 <i>subject</i> is the subject string that has just been successfully matched,
1321 <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 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 </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 value of zero extracts the substring that matched the entire pattern, whereas
1333 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 </pre>
1342 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 </pre>
1347 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 memory that is obtained via <b>pcre_malloc</b>. The address of the memory block
1353 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 </pre>
1359 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 <br><a name="SEC15" href="#TOC1">EXTRACTING CAPTURED SUBSTRINGS BY NAME</a><br>
1381 <P>
1382 <b>int pcre_get_stringnumber(const pcre *<i>code</i>,</b>
1383 <b>const char *<i>name</i>);</b>
1384 </P>
1385 <P>
1386 <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 To extract a substring by name, you first have to find associated number.
1399 For example, for this pattern
1400 <pre>
1401 (a+)b(?P&#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 </P>
1409 <P>
1410 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 </P>
1414 <P>
1415 Most of the arguments of <i>pcre_copy_named_substring()</i> and
1416 <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 </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 <br><a name="SEC16" href="#TOC1">FINDING ALL POSSIBLE MATCHES</a><br>
1432 <P>
1433 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>
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>
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>
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 <br>
1615 Copyright &copy; 1997-2005 University of Cambridge.
1616 <p>
1617 Return to the <a href="index.html">PCRE index page</a>.
1618 </p>

  ViewVC Help
Powered by ViewVC 1.1.5