1 |
.TH PCRE 3
|
2 |
.SH NAME
|
3 |
PCRE - Perl-compatible regular expressions
|
4 |
.SH SYNOPSIS OF PCRE API
|
5 |
.rs
|
6 |
.sp
|
7 |
.B #include <pcre.h>
|
8 |
.PP
|
9 |
.SM
|
10 |
.br
|
11 |
.B pcre *pcre_compile(const char *\fIpattern\fR, int \fIoptions\fR,
|
12 |
.ti +5n
|
13 |
.B const char **\fIerrptr\fR, int *\fIerroffset\fR,
|
14 |
.ti +5n
|
15 |
.B const unsigned char *\fItableptr\fR);
|
16 |
.PP
|
17 |
.br
|
18 |
.B pcre_extra *pcre_study(const pcre *\fIcode\fR, int \fIoptions\fR,
|
19 |
.ti +5n
|
20 |
.B const char **\fIerrptr\fR);
|
21 |
.PP
|
22 |
.br
|
23 |
.B int pcre_exec(const pcre *\fIcode\fR, "const pcre_extra *\fIextra\fR,"
|
24 |
.ti +5n
|
25 |
.B "const char *\fIsubject\fR," int \fIlength\fR, int \fIstartoffset\fR,
|
26 |
.ti +5n
|
27 |
.B int \fIoptions\fR, int *\fIovector\fR, int \fIovecsize\fR);
|
28 |
.PP
|
29 |
.br
|
30 |
.B int pcre_copy_named_substring(const pcre *\fIcode\fR,
|
31 |
.ti +5n
|
32 |
.B const char *\fIsubject\fR, int *\fIovector\fR,
|
33 |
.ti +5n
|
34 |
.B int \fIstringcount\fR, const char *\fIstringname\fR,
|
35 |
.ti +5n
|
36 |
.B char *\fIbuffer\fR, int \fIbuffersize\fR);
|
37 |
.PP
|
38 |
.br
|
39 |
.B int pcre_copy_substring(const char *\fIsubject\fR, int *\fIovector\fR,
|
40 |
.ti +5n
|
41 |
.B int \fIstringcount\fR, int \fIstringnumber\fR, char *\fIbuffer\fR,
|
42 |
.ti +5n
|
43 |
.B int \fIbuffersize\fR);
|
44 |
.PP
|
45 |
.br
|
46 |
.B int pcre_get_named_substring(const pcre *\fIcode\fR,
|
47 |
.ti +5n
|
48 |
.B const char *\fIsubject\fR, int *\fIovector\fR,
|
49 |
.ti +5n
|
50 |
.B int \fIstringcount\fR, const char *\fIstringname\fR,
|
51 |
.ti +5n
|
52 |
.B const char **\fIstringptr\fR);
|
53 |
.PP
|
54 |
.br
|
55 |
.B int pcre_get_stringnumber(const pcre *\fIcode\fR,
|
56 |
.ti +5n
|
57 |
.B const char *\fIname\fR);
|
58 |
.PP
|
59 |
.br
|
60 |
.B int pcre_get_substring(const char *\fIsubject\fR, int *\fIovector\fR,
|
61 |
.ti +5n
|
62 |
.B int \fIstringcount\fR, int \fIstringnumber\fR,
|
63 |
.ti +5n
|
64 |
.B const char **\fIstringptr\fR);
|
65 |
.PP
|
66 |
.br
|
67 |
.B int pcre_get_substring_list(const char *\fIsubject\fR,
|
68 |
.ti +5n
|
69 |
.B int *\fIovector\fR, int \fIstringcount\fR, "const char ***\fIlistptr\fR);"
|
70 |
.PP
|
71 |
.br
|
72 |
.B void pcre_free_substring(const char *\fIstringptr\fR);
|
73 |
.PP
|
74 |
.br
|
75 |
.B void pcre_free_substring_list(const char **\fIstringptr\fR);
|
76 |
.PP
|
77 |
.br
|
78 |
.B const unsigned char *pcre_maketables(void);
|
79 |
.PP
|
80 |
.br
|
81 |
.B int pcre_fullinfo(const pcre *\fIcode\fR, "const pcre_extra *\fIextra\fR,"
|
82 |
.ti +5n
|
83 |
.B int \fIwhat\fR, void *\fIwhere\fR);
|
84 |
.PP
|
85 |
.br
|
86 |
.B int pcre_info(const pcre *\fIcode\fR, int *\fIoptptr\fR, int
|
87 |
.B *\fIfirstcharptr\fR);
|
88 |
.PP
|
89 |
.br
|
90 |
.B int pcre_config(int \fIwhat\fR, void *\fIwhere\fR);
|
91 |
.PP
|
92 |
.br
|
93 |
.B char *pcre_version(void);
|
94 |
.PP
|
95 |
.br
|
96 |
.B void *(*pcre_malloc)(size_t);
|
97 |
.PP
|
98 |
.br
|
99 |
.B void (*pcre_free)(void *);
|
100 |
.PP
|
101 |
.br
|
102 |
.B int (*pcre_callout)(pcre_callout_block *);
|
103 |
|
104 |
.SH PCRE API
|
105 |
.rs
|
106 |
.sp
|
107 |
PCRE has its own native API, which is described in this document. There is also
|
108 |
a set of wrapper functions that correspond to the POSIX regular expression API.
|
109 |
These are described in the \fBpcreposix\fR documentation.
|
110 |
|
111 |
The native API function prototypes are defined in the header file \fBpcre.h\fR,
|
112 |
and on Unix systems the library itself is called \fBlibpcre.a\fR, so can be
|
113 |
accessed by adding \fB-lpcre\fR to the command for linking an application which
|
114 |
calls it. The header file defines the macros PCRE_MAJOR and PCRE_MINOR to
|
115 |
contain the major and minor release numbers for the library. Applications can
|
116 |
use these to include support for different releases.
|
117 |
|
118 |
The functions \fBpcre_compile()\fR, \fBpcre_study()\fR, and \fBpcre_exec()\fR
|
119 |
are used for compiling and matching regular expressions. A sample program that
|
120 |
demonstrates the simplest way of using them is given in the file
|
121 |
\fIpcredemo.c\fR. The \fBpcresample\fR documentation describes how to run it.
|
122 |
|
123 |
There are convenience functions for extracting captured substrings from a
|
124 |
matched subject string. They are:
|
125 |
|
126 |
\fBpcre_copy_substring()\fR
|
127 |
\fBpcre_copy_named_substring()\fR
|
128 |
\fBpcre_get_substring()\fR
|
129 |
\fBpcre_get_named_substring()\fR
|
130 |
\fBpcre_get_substring_list()\fR
|
131 |
|
132 |
\fBpcre_free_substring()\fR and \fBpcre_free_substring_list()\fR are also
|
133 |
provided, to free the memory used for extracted strings.
|
134 |
|
135 |
The function \fBpcre_maketables()\fR is used (optionally) to build a set of
|
136 |
character tables in the current locale for passing to \fBpcre_compile()\fR.
|
137 |
|
138 |
The function \fBpcre_fullinfo()\fR is used to find out information about a
|
139 |
compiled pattern; \fBpcre_info()\fR is an obsolete version which returns only
|
140 |
some of the available information, but is retained for backwards compatibility.
|
141 |
The function \fBpcre_version()\fR returns a pointer to a string containing the
|
142 |
version of PCRE and its date of release.
|
143 |
|
144 |
The global variables \fBpcre_malloc\fR and \fBpcre_free\fR initially contain
|
145 |
the entry points of the standard \fBmalloc()\fR and \fBfree()\fR functions
|
146 |
respectively. PCRE calls the memory management functions via these variables,
|
147 |
so a calling program can replace them if it wishes to intercept the calls. This
|
148 |
should be done before calling any PCRE functions.
|
149 |
|
150 |
The global variable \fBpcre_callout\fR initially contains NULL. It can be set
|
151 |
by the caller to a "callout" function, which PCRE will then call at specified
|
152 |
points during a matching operation. Details are given in the \fBpcrecallout\fR
|
153 |
documentation.
|
154 |
|
155 |
.SH MULTITHREADING
|
156 |
.rs
|
157 |
.sp
|
158 |
The PCRE functions can be used in multi-threading applications, with the
|
159 |
proviso that the memory management functions pointed to by \fBpcre_malloc\fR
|
160 |
and \fBpcre_free\fR, and the callout function pointed to by \fBpcre_callout\fR,
|
161 |
are shared by all threads.
|
162 |
|
163 |
The compiled form of a regular expression is not altered during matching, so
|
164 |
the same compiled pattern can safely be used by several threads at once.
|
165 |
|
166 |
.SH CHECKING BUILD-TIME OPTIONS
|
167 |
.rs
|
168 |
.sp
|
169 |
.B int pcre_config(int \fIwhat\fR, void *\fIwhere\fR);
|
170 |
.PP
|
171 |
The function \fBpcre_config()\fR makes it possible for a PCRE client to
|
172 |
discover which optional features have been compiled into the PCRE library. The
|
173 |
.\" HREF
|
174 |
\fBpcrebuild\fR
|
175 |
.\"
|
176 |
documentation has more details about these optional features.
|
177 |
|
178 |
The first argument for \fBpcre_config()\fR is an integer, specifying which
|
179 |
information is required; the second argument is a pointer to a variable into
|
180 |
which the information is placed. The following information is available:
|
181 |
|
182 |
PCRE_CONFIG_UTF8
|
183 |
|
184 |
The output is an integer that is set to one if UTF-8 support is available;
|
185 |
otherwise it is set to zero.
|
186 |
|
187 |
PCRE_CONFIG_NEWLINE
|
188 |
|
189 |
The output is an integer that is set to the value of the code that is used for
|
190 |
the newline character. It is either linefeed (10) or carriage return (13), and
|
191 |
should normally be the standard character for your operating system.
|
192 |
|
193 |
PCRE_CONFIG_LINK_SIZE
|
194 |
|
195 |
The output is an integer that contains the number of bytes used for internal
|
196 |
linkage in compiled regular expressions. The value is 2, 3, or 4. Larger values
|
197 |
allow larger regular expressions to be compiled, at the expense of slower
|
198 |
matching. The default value of 2 is sufficient for all but the most massive
|
199 |
patterns, since it allows the compiled pattern to be up to 64K in size.
|
200 |
|
201 |
PCRE_CONFIG_POSIX_MALLOC_THRESHOLD
|
202 |
|
203 |
The output is an integer that contains the threshold above which the POSIX
|
204 |
interface uses \fBmalloc()\fR for output vectors. Further details are given in
|
205 |
the \fBpcreposix\fR documentation.
|
206 |
|
207 |
PCRE_CONFIG_MATCH_LIMIT
|
208 |
|
209 |
The output is an integer that gives the default limit for the number of
|
210 |
internal matching function calls in a \fBpcre_exec()\fR execution. Further
|
211 |
details are given with \fBpcre_exec()\fR below.
|
212 |
|
213 |
.SH COMPILING A PATTERN
|
214 |
.rs
|
215 |
.sp
|
216 |
.B pcre *pcre_compile(const char *\fIpattern\fR, int \fIoptions\fR,
|
217 |
.ti +5n
|
218 |
.B const char **\fIerrptr\fR, int *\fIerroffset\fR,
|
219 |
.ti +5n
|
220 |
.B const unsigned char *\fItableptr\fR);
|
221 |
.PP
|
222 |
|
223 |
The function \fBpcre_compile()\fR is called to compile a pattern into an
|
224 |
internal form. The pattern is a C string terminated by a binary zero, and
|
225 |
is passed in the argument \fIpattern\fR. A pointer to a single block of memory
|
226 |
that is obtained via \fBpcre_malloc\fR is returned. This contains the compiled
|
227 |
code and related data. The \fBpcre\fR type is defined for the returned block;
|
228 |
this is a typedef for a structure whose contents are not externally defined. It
|
229 |
is up to the caller to free the memory when it is no longer required.
|
230 |
|
231 |
Although the compiled code of a PCRE regex is relocatable, that is, it does not
|
232 |
depend on memory location, the complete \fBpcre\fR data block is not
|
233 |
fully relocatable, because it contains a copy of the \fItableptr\fR argument,
|
234 |
which is an address (see below).
|
235 |
|
236 |
The \fIoptions\fR argument contains independent bits that affect the
|
237 |
compilation. It should be zero if no options are required. Some of the options,
|
238 |
in particular, those that are compatible with Perl, can also be set and unset
|
239 |
from within the pattern (see the detailed description of regular expressions
|
240 |
in the \fBpcrepattern\fR documentation). For these options, the contents of the
|
241 |
\fIoptions\fR argument specifies their initial settings at the start of
|
242 |
compilation and execution. The PCRE_ANCHORED option can be set at the time of
|
243 |
matching as well as at compile time.
|
244 |
|
245 |
If \fIerrptr\fR is NULL, \fBpcre_compile()\fR returns NULL immediately.
|
246 |
Otherwise, if compilation of a pattern fails, \fBpcre_compile()\fR returns
|
247 |
NULL, and sets the variable pointed to by \fIerrptr\fR to point to a textual
|
248 |
error message. The offset from the start of the pattern to the character where
|
249 |
the error was discovered is placed in the variable pointed to by
|
250 |
\fIerroffset\fR, which must not be NULL. If it is, an immediate error is given.
|
251 |
|
252 |
If the final argument, \fItableptr\fR, is NULL, PCRE uses a default set of
|
253 |
character tables which are built when it is compiled, using the default C
|
254 |
locale. Otherwise, \fItableptr\fR must be the result of a call to
|
255 |
\fBpcre_maketables()\fR. See the section on locale support below.
|
256 |
|
257 |
This code fragment shows a typical straightforward call to \fBpcre_compile()\fR:
|
258 |
|
259 |
pcre *re;
|
260 |
const char *error;
|
261 |
int erroffset;
|
262 |
re = pcre_compile(
|
263 |
"^A.*Z", /* the pattern */
|
264 |
0, /* default options */
|
265 |
&error, /* for error message */
|
266 |
&erroffset, /* for error offset */
|
267 |
NULL); /* use default character tables */
|
268 |
|
269 |
The following option bits are defined:
|
270 |
|
271 |
PCRE_ANCHORED
|
272 |
|
273 |
If this bit is set, the pattern is forced to be "anchored", that is, it is
|
274 |
constrained to match only at the first matching point in the string which is
|
275 |
being searched (the "subject string"). This effect can also be achieved by
|
276 |
appropriate constructs in the pattern itself, which is the only way to do it in
|
277 |
Perl.
|
278 |
|
279 |
PCRE_CASELESS
|
280 |
|
281 |
If this bit is set, letters in the pattern match both upper and lower case
|
282 |
letters. It is equivalent to Perl's /i option, and it can be changed within a
|
283 |
pattern by a (?i) option setting.
|
284 |
|
285 |
PCRE_DOLLAR_ENDONLY
|
286 |
|
287 |
If this bit is set, a dollar metacharacter in the pattern matches only at the
|
288 |
end of the subject string. Without this option, a dollar also matches
|
289 |
immediately before the final character if it is a newline (but not before any
|
290 |
other newlines). The PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is
|
291 |
set. There is no equivalent to this option in Perl, and no way to set it within
|
292 |
a pattern.
|
293 |
|
294 |
PCRE_DOTALL
|
295 |
|
296 |
If this bit is set, a dot metacharater in the pattern matches all characters,
|
297 |
including newlines. Without it, newlines are excluded. This option is
|
298 |
equivalent to Perl's /s option, and it can be changed within a pattern by a
|
299 |
(?s) option setting. A negative class such as [^a] always matches a newline
|
300 |
character, independent of the setting of this option.
|
301 |
|
302 |
PCRE_EXTENDED
|
303 |
|
304 |
If this bit is set, whitespace data characters in the pattern are totally
|
305 |
ignored except when escaped or inside a character class. Whitespace does not
|
306 |
include the VT character (code 11). In addition, characters between an
|
307 |
unescaped # outside a character class and the next newline character,
|
308 |
inclusive, are also ignored. This is equivalent to Perl's /x option, and it can
|
309 |
be changed within a pattern by a (?x) option setting.
|
310 |
|
311 |
This option makes it possible to include comments inside complicated patterns.
|
312 |
Note, however, that this applies only to data characters. Whitespace characters
|
313 |
may never appear within special character sequences in a pattern, for example
|
314 |
within the sequence (?( which introduces a conditional subpattern.
|
315 |
|
316 |
PCRE_EXTRA
|
317 |
|
318 |
This option was invented in order to turn on additional functionality of PCRE
|
319 |
that is incompatible with Perl, but it is currently of very little use. When
|
320 |
set, any backslash in a pattern that is followed by a letter that has no
|
321 |
special meaning causes an error, thus reserving these combinations for future
|
322 |
expansion. By default, as in Perl, a backslash followed by a letter with no
|
323 |
special meaning is treated as a literal. There are at present no other features
|
324 |
controlled by this option. It can also be set by a (?X) option setting within a
|
325 |
pattern.
|
326 |
|
327 |
PCRE_MULTILINE
|
328 |
|
329 |
By default, PCRE treats the subject string as consisting of a single "line" of
|
330 |
characters (even if it actually contains several newlines). The "start of line"
|
331 |
metacharacter (^) matches only at the start of the string, while the "end of
|
332 |
line" metacharacter ($) matches only at the end of the string, or before a
|
333 |
terminating newline (unless PCRE_DOLLAR_ENDONLY is set). This is the same as
|
334 |
Perl.
|
335 |
|
336 |
When PCRE_MULTILINE it is set, the "start of line" and "end of line" constructs
|
337 |
match immediately following or immediately before any newline in the subject
|
338 |
string, respectively, as well as at the very start and end. This is equivalent
|
339 |
to Perl's /m option, and it can be changed within a pattern by a (?m) option
|
340 |
setting. If there are no "\\n" characters in a subject string, or no
|
341 |
occurrences of ^ or $ in a pattern, setting PCRE_MULTILINE has no effect.
|
342 |
|
343 |
PCRE_NO_AUTO_CAPTURE
|
344 |
|
345 |
If this option is set, it disables the use of numbered capturing parentheses in
|
346 |
the pattern. Any opening parenthesis that is not followed by ? behaves as if it
|
347 |
were followed by ?: but named parentheses can still be used for capturing (and
|
348 |
they acquire numbers in the usual way). There is no equivalent of this option
|
349 |
in Perl.
|
350 |
|
351 |
PCRE_UNGREEDY
|
352 |
|
353 |
This option inverts the "greediness" of the quantifiers so that they are not
|
354 |
greedy by default, but become greedy if followed by "?". It is not compatible
|
355 |
with Perl. It can also be set by a (?U) option setting within the pattern.
|
356 |
|
357 |
PCRE_UTF8
|
358 |
|
359 |
This option causes PCRE to regard both the pattern and the subject as strings
|
360 |
of UTF-8 characters instead of single-byte character strings. However, it is
|
361 |
available only if PCRE has been built to include UTF-8 support. If not, the use
|
362 |
of this option provokes an error. Details of how this option changes the
|
363 |
behaviour of PCRE are given in the
|
364 |
.\" HTML <a href="pcre.html#utf8support">
|
365 |
.\" </a>
|
366 |
section on UTF-8 support
|
367 |
.\"
|
368 |
in the main
|
369 |
.\" HREF
|
370 |
\fBpcre\fR
|
371 |
.\"
|
372 |
page.
|
373 |
|
374 |
.SH STUDYING A PATTERN
|
375 |
.rs
|
376 |
.sp
|
377 |
.B pcre_extra *pcre_study(const pcre *\fIcode\fR, int \fIoptions\fR,
|
378 |
.ti +5n
|
379 |
.B const char **\fIerrptr\fR);
|
380 |
.PP
|
381 |
When a pattern is going to be used several times, it is worth spending more
|
382 |
time analyzing it in order to speed up the time taken for matching. The
|
383 |
function \fBpcre_study()\fR takes a pointer to a compiled pattern as its first
|
384 |
argument. If studing the pattern produces additional information that will help
|
385 |
speed up matching, \fBpcre_study()\fR returns a pointer to a \fBpcre_extra\fR
|
386 |
block, in which the \fIstudy_data\fR field points to the results of the study.
|
387 |
|
388 |
The returned value from a \fBpcre_study()\fR can be passed directly to
|
389 |
\fBpcre_exec()\fR. However, the \fBpcre_extra\fR block also contains other
|
390 |
fields that can be set by the caller before the block is passed; these are
|
391 |
described below. If studying the pattern does not produce any additional
|
392 |
information, \fBpcre_study()\fR returns NULL. In that circumstance, if the
|
393 |
calling program wants to pass some of the other fields to \fBpcre_exec()\fR, it
|
394 |
must set up its own \fBpcre_extra\fR block.
|
395 |
|
396 |
The second argument contains option bits. At present, no options are defined
|
397 |
for \fBpcre_study()\fR, and this argument should always be zero.
|
398 |
|
399 |
The third argument for \fBpcre_study()\fR is a pointer for an error message. If
|
400 |
studying succeeds (even if no data is returned), the variable it points to is
|
401 |
set to NULL. Otherwise it points to a textual error message. You should
|
402 |
therefore test the error pointer for NULL after calling \fBpcre_study()\fR, to
|
403 |
be sure that it has run successfully.
|
404 |
|
405 |
This is a typical call to \fBpcre_study\fR():
|
406 |
|
407 |
pcre_extra *pe;
|
408 |
pe = pcre_study(
|
409 |
re, /* result of pcre_compile() */
|
410 |
0, /* no options exist */
|
411 |
&error); /* set to NULL or points to a message */
|
412 |
|
413 |
At present, studying a pattern is useful only for non-anchored patterns that do
|
414 |
not have a single fixed starting character. A bitmap of possible starting
|
415 |
characters is created.
|
416 |
|
417 |
.\" HTML <a name="localesupport"></a>
|
418 |
.SH LOCALE SUPPORT
|
419 |
.rs
|
420 |
.sp
|
421 |
PCRE handles caseless matching, and determines whether characters are letters,
|
422 |
digits, or whatever, by reference to a set of tables. When running in UTF-8
|
423 |
mode, this applies only to characters with codes less than 256. The library
|
424 |
contains a default set of tables that is created in the default C locale when
|
425 |
PCRE is compiled. This is used when the final argument of \fBpcre_compile()\fR
|
426 |
is NULL, and is sufficient for many applications.
|
427 |
|
428 |
An alternative set of tables can, however, be supplied. Such tables are built
|
429 |
by calling the \fBpcre_maketables()\fR function, which has no arguments, in the
|
430 |
relevant locale. The result can then be passed to \fBpcre_compile()\fR as often
|
431 |
as necessary. For example, to build and use tables that are appropriate for the
|
432 |
French locale (where accented characters with codes greater than 128 are
|
433 |
treated as letters), the following code could be used:
|
434 |
|
435 |
setlocale(LC_CTYPE, "fr");
|
436 |
tables = pcre_maketables();
|
437 |
re = pcre_compile(..., tables);
|
438 |
|
439 |
The tables are built in memory that is obtained via \fBpcre_malloc\fR. The
|
440 |
pointer that is passed to \fBpcre_compile\fR is saved with the compiled
|
441 |
pattern, and the same tables are used via this pointer by \fBpcre_study()\fR
|
442 |
and \fBpcre_exec()\fR. Thus, for any single pattern, compilation, studying and
|
443 |
matching all happen in the same locale, but different patterns can be compiled
|
444 |
in different locales. It is the caller's responsibility to ensure that the
|
445 |
memory containing the tables remains available for as long as it is needed.
|
446 |
|
447 |
.SH INFORMATION ABOUT A PATTERN
|
448 |
.rs
|
449 |
.sp
|
450 |
.B int pcre_fullinfo(const pcre *\fIcode\fR, "const pcre_extra *\fIextra\fR,"
|
451 |
.ti +5n
|
452 |
.B int \fIwhat\fR, void *\fIwhere\fR);
|
453 |
.PP
|
454 |
The \fBpcre_fullinfo()\fR function returns information about a compiled
|
455 |
pattern. It replaces the obsolete \fBpcre_info()\fR function, which is
|
456 |
nevertheless retained for backwards compability (and is documented below).
|
457 |
|
458 |
The first argument for \fBpcre_fullinfo()\fR is a pointer to the compiled
|
459 |
pattern. The second argument is the result of \fBpcre_study()\fR, or NULL if
|
460 |
the pattern was not studied. The third argument specifies which piece of
|
461 |
information is required, and the fourth argument is a pointer to a variable
|
462 |
to receive the data. The yield of the function is zero for success, or one of
|
463 |
the following negative numbers:
|
464 |
|
465 |
PCRE_ERROR_NULL the argument \fIcode\fR was NULL
|
466 |
the argument \fIwhere\fR was NULL
|
467 |
PCRE_ERROR_BADMAGIC the "magic number" was not found
|
468 |
PCRE_ERROR_BADOPTION the value of \fIwhat\fR was invalid
|
469 |
|
470 |
Here is a typical call of \fBpcre_fullinfo()\fR, to obtain the length of the
|
471 |
compiled pattern:
|
472 |
|
473 |
int rc;
|
474 |
unsigned long int length;
|
475 |
rc = pcre_fullinfo(
|
476 |
re, /* result of pcre_compile() */
|
477 |
pe, /* result of pcre_study(), or NULL */
|
478 |
PCRE_INFO_SIZE, /* what is required */
|
479 |
&length); /* where to put the data */
|
480 |
|
481 |
The possible values for the third argument are defined in \fBpcre.h\fR, and are
|
482 |
as follows:
|
483 |
|
484 |
PCRE_INFO_BACKREFMAX
|
485 |
|
486 |
Return the number of the highest back reference in the pattern. The fourth
|
487 |
argument should point to an \fBint\fR variable. Zero is returned if there are
|
488 |
no back references.
|
489 |
|
490 |
PCRE_INFO_CAPTURECOUNT
|
491 |
|
492 |
Return the number of capturing subpatterns in the pattern. The fourth argument
|
493 |
should point to an \fbint\fR variable.
|
494 |
|
495 |
PCRE_INFO_FIRSTBYTE
|
496 |
|
497 |
Return information about the first byte of any matched string, for a
|
498 |
non-anchored pattern. (This option used to be called PCRE_INFO_FIRSTCHAR; the
|
499 |
old name is still recognized for backwards compatibility.)
|
500 |
|
501 |
If there is a fixed first byte, e.g. from a pattern such as (cat|cow|coyote),
|
502 |
it is returned in the integer pointed to by \fIwhere\fR. Otherwise, if either
|
503 |
|
504 |
(a) the pattern was compiled with the PCRE_MULTILINE option, and every branch
|
505 |
starts with "^", or
|
506 |
|
507 |
(b) every branch of the pattern starts with ".*" and PCRE_DOTALL is not set
|
508 |
(if it were set, the pattern would be anchored),
|
509 |
|
510 |
-1 is returned, indicating that the pattern matches only at the start of a
|
511 |
subject string or after any newline within the string. Otherwise -2 is
|
512 |
returned. For anchored patterns, -2 is returned.
|
513 |
|
514 |
PCRE_INFO_FIRSTTABLE
|
515 |
|
516 |
If the pattern was studied, and this resulted in the construction of a 256-bit
|
517 |
table indicating a fixed set of bytes for the first byte in any matching
|
518 |
string, a pointer to the table is returned. Otherwise NULL is returned. The
|
519 |
fourth argument should point to an \fBunsigned char *\fR variable.
|
520 |
|
521 |
PCRE_INFO_LASTLITERAL
|
522 |
|
523 |
For a non-anchored pattern, return the value of the rightmost literal byte
|
524 |
which must exist in any matched string, other than at its start. The fourth
|
525 |
argument should point to an \fBint\fR variable. If there is no such byte, or if
|
526 |
the pattern is anchored, -1 is returned. For example, for the pattern
|
527 |
/a\\d+z\\d+/ the returned value is 'z'.
|
528 |
|
529 |
PCRE_INFO_NAMECOUNT
|
530 |
PCRE_INFO_NAMEENTRYSIZE
|
531 |
PCRE_INFO_NAMETABLE
|
532 |
|
533 |
PCRE supports the use of named as well as numbered capturing parentheses. The
|
534 |
names are just an additional way of identifying the parentheses, which still
|
535 |
acquire a number. A caller that wants to extract data from a named subpattern
|
536 |
must convert the name to a number in order to access the correct pointers in
|
537 |
the output vector (described with \fBpcre_exec()\fR below). In order to do
|
538 |
this, it must first use these three values to obtain the name-to-number mapping
|
539 |
table for the pattern.
|
540 |
|
541 |
The map consists of a number of fixed-size entries. PCRE_INFO_NAMECOUNT gives
|
542 |
the number of entries, and PCRE_INFO_NAMEENTRYSIZE gives the size of each
|
543 |
entry; both of these return an \fBint\fR value. The entry size depends on the
|
544 |
length of the longest name. PCRE_INFO_NAMETABLE returns a pointer to the first
|
545 |
entry of the table (a pointer to \fBchar\fR). The first two bytes of each entry
|
546 |
are the number of the capturing parenthesis, most significant byte first. The
|
547 |
rest of the entry is the corresponding name, zero terminated. The names are in
|
548 |
alphabetical order. For example, consider the following pattern (assume
|
549 |
PCRE_EXTENDED is set, so white space - including newlines - is ignored):
|
550 |
|
551 |
(?P<date> (?P<year>(\\d\\d)?\\d\\d) -
|
552 |
(?P<month>\\d\\d) - (?P<day>\\d\\d) )
|
553 |
|
554 |
There are four named subpatterns, so the table has four entries, and each entry
|
555 |
in the table is eight bytes long. The table is as follows, with non-printing
|
556 |
bytes shows in hex, and undefined bytes shown as ??:
|
557 |
|
558 |
00 01 d a t e 00 ??
|
559 |
00 05 d a y 00 ?? ??
|
560 |
00 04 m o n t h 00
|
561 |
00 02 y e a r 00 ??
|
562 |
|
563 |
When writing code to extract data from named subpatterns, remember that the
|
564 |
length of each entry may be different for each compiled pattern.
|
565 |
|
566 |
PCRE_INFO_OPTIONS
|
567 |
|
568 |
Return a copy of the options with which the pattern was compiled. The fourth
|
569 |
argument should point to an \fBunsigned long int\fR variable. These option bits
|
570 |
are those specified in the call to \fBpcre_compile()\fR, modified by any
|
571 |
top-level option settings within the pattern itself.
|
572 |
|
573 |
A pattern is automatically anchored by PCRE if all of its top-level
|
574 |
alternatives begin with one of the following:
|
575 |
|
576 |
^ unless PCRE_MULTILINE is set
|
577 |
\\A always
|
578 |
\\G always
|
579 |
.* if PCRE_DOTALL is set and there are no back
|
580 |
references to the subpattern in which .* appears
|
581 |
|
582 |
For such patterns, the PCRE_ANCHORED bit is set in the options returned by
|
583 |
\fBpcre_fullinfo()\fR.
|
584 |
|
585 |
PCRE_INFO_SIZE
|
586 |
|
587 |
Return the size of the compiled pattern, that is, the value that was passed as
|
588 |
the argument to \fBpcre_malloc()\fR when PCRE was getting memory in which to
|
589 |
place the compiled data. The fourth argument should point to a \fBsize_t\fR
|
590 |
variable.
|
591 |
|
592 |
PCRE_INFO_STUDYSIZE
|
593 |
|
594 |
Returns the size of the data block pointed to by the \fIstudy_data\fR field in
|
595 |
a \fBpcre_extra\fR block. That is, it is the value that was passed to
|
596 |
\fBpcre_malloc()\fR when PCRE was getting memory into which to place the data
|
597 |
created by \fBpcre_study()\fR. The fourth argument should point to a
|
598 |
\fBsize_t\fR variable.
|
599 |
|
600 |
.SH OBSOLETE INFO FUNCTION
|
601 |
.rs
|
602 |
.sp
|
603 |
.B int pcre_info(const pcre *\fIcode\fR, int *\fIoptptr\fR, int
|
604 |
.B *\fIfirstcharptr\fR);
|
605 |
.PP
|
606 |
The \fBpcre_info()\fR function is now obsolete because its interface is too
|
607 |
restrictive to return all the available data about a compiled pattern. New
|
608 |
programs should use \fBpcre_fullinfo()\fR instead. The yield of
|
609 |
\fBpcre_info()\fR is the number of capturing subpatterns, or one of the
|
610 |
following negative numbers:
|
611 |
|
612 |
PCRE_ERROR_NULL the argument \fIcode\fR was NULL
|
613 |
PCRE_ERROR_BADMAGIC the "magic number" was not found
|
614 |
|
615 |
If the \fIoptptr\fR argument is not NULL, a copy of the options with which the
|
616 |
pattern was compiled is placed in the integer it points to (see
|
617 |
PCRE_INFO_OPTIONS above).
|
618 |
|
619 |
If the pattern is not anchored and the \fIfirstcharptr\fR argument is not NULL,
|
620 |
it is used to pass back information about the first character of any matched
|
621 |
string (see PCRE_INFO_FIRSTBYTE above).
|
622 |
|
623 |
.SH MATCHING A PATTERN
|
624 |
.rs
|
625 |
.sp
|
626 |
.B int pcre_exec(const pcre *\fIcode\fR, "const pcre_extra *\fIextra\fR,"
|
627 |
.ti +5n
|
628 |
.B "const char *\fIsubject\fR," int \fIlength\fR, int \fIstartoffset\fR,
|
629 |
.ti +5n
|
630 |
.B int \fIoptions\fR, int *\fIovector\fR, int \fIovecsize\fR);
|
631 |
.PP
|
632 |
The function \fBpcre_exec()\fR is called to match a subject string against a
|
633 |
pre-compiled pattern, which is passed in the \fIcode\fR argument. If the
|
634 |
pattern has been studied, the result of the study should be passed in the
|
635 |
\fIextra\fR argument.
|
636 |
|
637 |
Here is an example of a simple call to \fBpcre_exec()\fR:
|
638 |
|
639 |
int rc;
|
640 |
int ovector[30];
|
641 |
rc = pcre_exec(
|
642 |
re, /* result of pcre_compile() */
|
643 |
NULL, /* we didn't study the pattern */
|
644 |
"some string", /* the subject string */
|
645 |
11, /* the length of the subject string */
|
646 |
0, /* start at offset 0 in the subject */
|
647 |
0, /* default options */
|
648 |
ovector, /* vector for substring information */
|
649 |
30); /* number of elements in the vector */
|
650 |
|
651 |
If the \fIextra\fR argument is not NULL, it must point to a \fBpcre_extra\fR
|
652 |
data block. The \fBpcre_study()\fR function returns such a block (when it
|
653 |
doesn't return NULL), but you can also create one for yourself, and pass
|
654 |
additional information in it. The fields in the block are as follows:
|
655 |
|
656 |
unsigned long int \fIflags\fR;
|
657 |
void *\fIstudy_data\fR;
|
658 |
unsigned long int \fImatch_limit\fR;
|
659 |
void *\fIcallout_data\fR;
|
660 |
|
661 |
The \fIflags\fR field is a bitmap that specifies which of the other fields
|
662 |
are set. The flag bits are:
|
663 |
|
664 |
PCRE_EXTRA_STUDY_DATA
|
665 |
PCRE_EXTRA_MATCH_LIMIT
|
666 |
PCRE_EXTRA_CALLOUT_DATA
|
667 |
|
668 |
Other flag bits should be set to zero. The \fIstudy_data\fR field is set in the
|
669 |
\fBpcre_extra\fR block that is returned by \fBpcre_study()\fR, together with
|
670 |
the appropriate flag bit. You should not set this yourself, but you can add to
|
671 |
the block by setting the other fields.
|
672 |
|
673 |
The \fImatch_limit\fR field provides a means of preventing PCRE from using up a
|
674 |
vast amount of resources when running patterns that are not going to match,
|
675 |
but which have a very large number of possibilities in their search trees. The
|
676 |
classic example is the use of nested unlimited repeats. Internally, PCRE uses a
|
677 |
function called \fBmatch()\fR which it calls repeatedly (sometimes
|
678 |
recursively). The limit is imposed on the number of times this function is
|
679 |
called during a match, which has the effect of limiting the amount of recursion
|
680 |
and backtracking that can take place. For patterns that are not anchored, the
|
681 |
count starts from zero for each position in the subject string.
|
682 |
|
683 |
The default limit for the library can be set when PCRE is built; the default
|
684 |
default is 10 million, which handles all but the most extreme cases. You can
|
685 |
reduce the default by suppling \fBpcre_exec()\fR with a \fRpcre_extra\fR block
|
686 |
in which \fImatch_limit\fR is set to a smaller value, and
|
687 |
PCRE_EXTRA_MATCH_LIMIT is set in the \fIflags\fR field. If the limit is
|
688 |
exceeded, \fBpcre_exec()\fR returns PCRE_ERROR_MATCHLIMIT.
|
689 |
|
690 |
The \fIpcre_callout\fR field is used in conjunction with the "callout" feature,
|
691 |
which is described in the \fBpcrecallout\fR documentation.
|
692 |
|
693 |
The PCRE_ANCHORED option can be passed in the \fIoptions\fR argument, whose
|
694 |
unused bits must be zero. This limits \fBpcre_exec()\fR to matching at the
|
695 |
first matching position. However, if a pattern was compiled with PCRE_ANCHORED,
|
696 |
or turned out to be anchored by virtue of its contents, it cannot be made
|
697 |
unachored at matching time.
|
698 |
|
699 |
There are also three further options that can be set only at matching time:
|
700 |
|
701 |
PCRE_NOTBOL
|
702 |
|
703 |
The first character of the string is not the beginning of a line, so the
|
704 |
circumflex metacharacter should not match before it. Setting this without
|
705 |
PCRE_MULTILINE (at compile time) causes circumflex never to match.
|
706 |
|
707 |
PCRE_NOTEOL
|
708 |
|
709 |
The end of the string is not the end of a line, so the dollar metacharacter
|
710 |
should not match it nor (except in multiline mode) a newline immediately before
|
711 |
it. Setting this without PCRE_MULTILINE (at compile time) causes dollar never
|
712 |
to match.
|
713 |
|
714 |
PCRE_NOTEMPTY
|
715 |
|
716 |
An empty string is not considered to be a valid match if this option is set. If
|
717 |
there are alternatives in the pattern, they are tried. If all the alternatives
|
718 |
match the empty string, the entire match fails. For example, if the pattern
|
719 |
|
720 |
a?b?
|
721 |
|
722 |
is applied to a string not beginning with "a" or "b", it matches the empty
|
723 |
string at the start of the subject. With PCRE_NOTEMPTY set, this match is not
|
724 |
valid, so PCRE searches further into the string for occurrences of "a" or "b".
|
725 |
|
726 |
Perl has no direct equivalent of PCRE_NOTEMPTY, but it does make a special case
|
727 |
of a pattern match of the empty string within its \fBsplit()\fR function, and
|
728 |
when using the /g modifier. It is possible to emulate Perl's behaviour after
|
729 |
matching a null string by first trying the match again at the same offset with
|
730 |
PCRE_NOTEMPTY set, and then if that fails by advancing the starting offset (see
|
731 |
below) and trying an ordinary match again.
|
732 |
|
733 |
The subject string is passed to \fBpcre_exec()\fR as a pointer in
|
734 |
\fIsubject\fR, a length in \fIlength\fR, and a starting offset in
|
735 |
\fIstartoffset\fR. Unlike the pattern string, the subject may contain binary
|
736 |
zero bytes. When the starting offset is zero, the search for a match starts at
|
737 |
the beginning of the subject, and this is by far the most common case.
|
738 |
|
739 |
If the pattern was compiled with the PCRE_UTF8 option, the subject must be a
|
740 |
sequence of bytes that is a valid UTF-8 string. If an invalid UTF-8 string is
|
741 |
passed, PCRE's behaviour is not defined.
|
742 |
|
743 |
A non-zero starting offset is useful when searching for another match in the
|
744 |
same subject by calling \fBpcre_exec()\fR again after a previous success.
|
745 |
Setting \fIstartoffset\fR differs from just passing over a shortened string and
|
746 |
setting PCRE_NOTBOL in the case of a pattern that begins with any kind of
|
747 |
lookbehind. For example, consider the pattern
|
748 |
|
749 |
\\Biss\\B
|
750 |
|
751 |
which finds occurrences of "iss" in the middle of words. (\\B matches only if
|
752 |
the current position in the subject is not a word boundary.) When applied to
|
753 |
the string "Mississipi" the first call to \fBpcre_exec()\fR finds the first
|
754 |
occurrence. If \fBpcre_exec()\fR is called again with just the remainder of the
|
755 |
subject, namely "issipi", it does not match, because \\B is always false at the
|
756 |
start of the subject, which is deemed to be a word boundary. However, if
|
757 |
\fBpcre_exec()\fR is passed the entire string again, but with \fIstartoffset\fR
|
758 |
set to 4, it finds the second occurrence of "iss" because it is able to look
|
759 |
behind the starting point to discover that it is preceded by a letter.
|
760 |
|
761 |
If a non-zero starting offset is passed when the pattern is anchored, one
|
762 |
attempt to match at the given offset is tried. This can only succeed if the
|
763 |
pattern does not require the match to be at the start of the subject.
|
764 |
|
765 |
In general, a pattern matches a certain portion of the subject, and in
|
766 |
addition, further substrings from the subject may be picked out by parts of the
|
767 |
pattern. Following the usage in Jeffrey Friedl's book, this is called
|
768 |
"capturing" in what follows, and the phrase "capturing subpattern" is used for
|
769 |
a fragment of a pattern that picks out a substring. PCRE supports several other
|
770 |
kinds of parenthesized subpattern that do not cause substrings to be captured.
|
771 |
|
772 |
Captured substrings are returned to the caller via a vector of integer offsets
|
773 |
whose address is passed in \fIovector\fR. The number of elements in the vector
|
774 |
is passed in \fIovecsize\fR. The first two-thirds of the vector is used to pass
|
775 |
back captured substrings, each substring using a pair of integers. The
|
776 |
remaining third of the vector is used as workspace by \fBpcre_exec()\fR while
|
777 |
matching capturing subpatterns, and is not available for passing back
|
778 |
information. The length passed in \fIovecsize\fR should always be a multiple of
|
779 |
three. If it is not, it is rounded down.
|
780 |
|
781 |
When a match has been successful, information about captured substrings is
|
782 |
returned in pairs of integers, starting at the beginning of \fIovector\fR, and
|
783 |
continuing up to two-thirds of its length at the most. The first element of a
|
784 |
pair is set to the offset of the first character in a substring, and the second
|
785 |
is set to the offset of the first character after the end of a substring. The
|
786 |
first pair, \fIovector[0]\fR and \fIovector[1]\fR, identify the portion of the
|
787 |
subject string matched by the entire pattern. The next pair is used for the
|
788 |
first capturing subpattern, and so on. The value returned by \fBpcre_exec()\fR
|
789 |
is the number of pairs that have been set. If there are no capturing
|
790 |
subpatterns, the return value from a successful match is 1, indicating that
|
791 |
just the first pair of offsets has been set.
|
792 |
|
793 |
Some convenience functions are provided for extracting the captured substrings
|
794 |
as separate strings. These are described in the following section.
|
795 |
|
796 |
It is possible for an capturing subpattern number \fIn+1\fR to match some
|
797 |
part of the subject when subpattern \fIn\fR has not been used at all. For
|
798 |
example, if the string "abc" is matched against the pattern (a|(z))(bc)
|
799 |
subpatterns 1 and 3 are matched, but 2 is not. When this happens, both offset
|
800 |
values corresponding to the unused subpattern are set to -1.
|
801 |
|
802 |
If a capturing subpattern is matched repeatedly, it is the last portion of the
|
803 |
string that it matched that gets returned.
|
804 |
|
805 |
If the vector is too small to hold all the captured substrings, it is used as
|
806 |
far as possible (up to two-thirds of its length), and the function returns a
|
807 |
value of zero. In particular, if the substring offsets are not of interest,
|
808 |
\fBpcre_exec()\fR may be called with \fIovector\fR passed as NULL and
|
809 |
\fIovecsize\fR as zero. However, if the pattern contains back references and
|
810 |
the \fIovector\fR isn't big enough to remember the related substrings, PCRE has
|
811 |
to get additional memory for use during matching. Thus it is usually advisable
|
812 |
to supply an \fIovector\fR.
|
813 |
|
814 |
Note that \fBpcre_info()\fR can be used to find out how many capturing
|
815 |
subpatterns there are in a compiled pattern. The smallest size for
|
816 |
\fIovector\fR that will allow for \fIn\fR captured substrings, in addition to
|
817 |
the offsets of the substring matched by the whole pattern, is (\fIn\fR+1)*3.
|
818 |
|
819 |
If \fBpcre_exec()\fR fails, it returns a negative number. The following are
|
820 |
defined in the header file:
|
821 |
|
822 |
PCRE_ERROR_NOMATCH (-1)
|
823 |
|
824 |
The subject string did not match the pattern.
|
825 |
|
826 |
PCRE_ERROR_NULL (-2)
|
827 |
|
828 |
Either \fIcode\fR or \fIsubject\fR was passed as NULL, or \fIovector\fR was
|
829 |
NULL and \fIovecsize\fR was not zero.
|
830 |
|
831 |
PCRE_ERROR_BADOPTION (-3)
|
832 |
|
833 |
An unrecognized bit was set in the \fIoptions\fR argument.
|
834 |
|
835 |
PCRE_ERROR_BADMAGIC (-4)
|
836 |
|
837 |
PCRE stores a 4-byte "magic number" at the start of the compiled code, to catch
|
838 |
the case when it is passed a junk pointer. This is the error it gives when the
|
839 |
magic number isn't present.
|
840 |
|
841 |
PCRE_ERROR_UNKNOWN_NODE (-5)
|
842 |
|
843 |
While running the pattern match, an unknown item was encountered in the
|
844 |
compiled pattern. This error could be caused by a bug in PCRE or by overwriting
|
845 |
of the compiled pattern.
|
846 |
|
847 |
PCRE_ERROR_NOMEMORY (-6)
|
848 |
|
849 |
If a pattern contains back references, but the \fIovector\fR that is passed to
|
850 |
\fBpcre_exec()\fR is not big enough to remember the referenced substrings, PCRE
|
851 |
gets a block of memory at the start of matching to use for this purpose. If the
|
852 |
call via \fBpcre_malloc()\fR fails, this error is given. The memory is freed at
|
853 |
the end of matching.
|
854 |
|
855 |
PCRE_ERROR_NOSUBSTRING (-7)
|
856 |
|
857 |
This error is used by the \fBpcre_copy_substring()\fR,
|
858 |
\fBpcre_get_substring()\fR, and \fBpcre_get_substring_list()\fR functions (see
|
859 |
below). It is never returned by \fBpcre_exec()\fR.
|
860 |
|
861 |
PCRE_ERROR_MATCHLIMIT (-8)
|
862 |
|
863 |
The recursion and backtracking limit, as specified by the \fImatch_limit\fR
|
864 |
field in a \fBpcre_extra\fR structure (or defaulted) was reached. See the
|
865 |
description above.
|
866 |
|
867 |
PCRE_ERROR_CALLOUT (-9)
|
868 |
|
869 |
This error is never generated by \fBpcre_exec()\fR itself. It is provided for
|
870 |
use by callout functions that want to yield a distinctive error code. See the
|
871 |
\fBpcrecallout\fR documentation for details.
|
872 |
|
873 |
.SH EXTRACTING CAPTURED SUBSTRINGS BY NUMBER
|
874 |
.rs
|
875 |
.sp
|
876 |
.B int pcre_copy_substring(const char *\fIsubject\fR, int *\fIovector\fR,
|
877 |
.ti +5n
|
878 |
.B int \fIstringcount\fR, int \fIstringnumber\fR, char *\fIbuffer\fR,
|
879 |
.ti +5n
|
880 |
.B int \fIbuffersize\fR);
|
881 |
.PP
|
882 |
.br
|
883 |
.B int pcre_get_substring(const char *\fIsubject\fR, int *\fIovector\fR,
|
884 |
.ti +5n
|
885 |
.B int \fIstringcount\fR, int \fIstringnumber\fR,
|
886 |
.ti +5n
|
887 |
.B const char **\fIstringptr\fR);
|
888 |
.PP
|
889 |
.br
|
890 |
.B int pcre_get_substring_list(const char *\fIsubject\fR,
|
891 |
.ti +5n
|
892 |
.B int *\fIovector\fR, int \fIstringcount\fR, "const char ***\fIlistptr\fR);"
|
893 |
.PP
|
894 |
Captured substrings can be accessed directly by using the offsets returned by
|
895 |
\fBpcre_exec()\fR in \fIovector\fR. For convenience, the functions
|
896 |
\fBpcre_copy_substring()\fR, \fBpcre_get_substring()\fR, and
|
897 |
\fBpcre_get_substring_list()\fR are provided for extracting captured substrings
|
898 |
as new, separate, zero-terminated strings. These functions identify substrings
|
899 |
by number. The next section describes functions for extracting named
|
900 |
substrings. A substring that contains a binary zero is correctly extracted and
|
901 |
has a further zero added on the end, but the result is not, of course,
|
902 |
a C string.
|
903 |
|
904 |
The first three arguments are the same for all three of these functions:
|
905 |
\fIsubject\fR is the subject string which has just been successfully matched,
|
906 |
\fIovector\fR is a pointer to the vector of integer offsets that was passed to
|
907 |
\fBpcre_exec()\fR, and \fIstringcount\fR is the number of substrings that were
|
908 |
captured by the match, including the substring that matched the entire regular
|
909 |
expression. This is the value returned by \fBpcre_exec\fR if it is greater than
|
910 |
zero. If \fBpcre_exec()\fR returned zero, indicating that it ran out of space
|
911 |
in \fIovector\fR, the value passed as \fIstringcount\fR should be the size of
|
912 |
the vector divided by three.
|
913 |
|
914 |
The functions \fBpcre_copy_substring()\fR and \fBpcre_get_substring()\fR
|
915 |
extract a single substring, whose number is given as \fIstringnumber\fR. A
|
916 |
value of zero extracts the substring that matched the entire pattern, while
|
917 |
higher values extract the captured substrings. For \fBpcre_copy_substring()\fR,
|
918 |
the string is placed in \fIbuffer\fR, whose length is given by
|
919 |
\fIbuffersize\fR, while for \fBpcre_get_substring()\fR a new block of memory is
|
920 |
obtained via \fBpcre_malloc\fR, and its address is returned via
|
921 |
\fIstringptr\fR. The yield of the function is the length of the string, not
|
922 |
including the terminating zero, or one of
|
923 |
|
924 |
PCRE_ERROR_NOMEMORY (-6)
|
925 |
|
926 |
The buffer was too small for \fBpcre_copy_substring()\fR, or the attempt to get
|
927 |
memory failed for \fBpcre_get_substring()\fR.
|
928 |
|
929 |
PCRE_ERROR_NOSUBSTRING (-7)
|
930 |
|
931 |
There is no substring whose number is \fIstringnumber\fR.
|
932 |
|
933 |
The \fBpcre_get_substring_list()\fR function extracts all available substrings
|
934 |
and builds a list of pointers to them. All this is done in a single block of
|
935 |
memory which is obtained via \fBpcre_malloc\fR. The address of the memory block
|
936 |
is returned via \fIlistptr\fR, which is also the start of the list of string
|
937 |
pointers. The end of the list is marked by a NULL pointer. The yield of the
|
938 |
function is zero if all went well, or
|
939 |
|
940 |
PCRE_ERROR_NOMEMORY (-6)
|
941 |
|
942 |
if the attempt to get the memory block failed.
|
943 |
|
944 |
When any of these functions encounter a substring that is unset, which can
|
945 |
happen when capturing subpattern number \fIn+1\fR matches some part of the
|
946 |
subject, but subpattern \fIn\fR has not been used at all, they return an empty
|
947 |
string. This can be distinguished from a genuine zero-length substring by
|
948 |
inspecting the appropriate offset in \fIovector\fR, which is negative for unset
|
949 |
substrings.
|
950 |
|
951 |
The two convenience functions \fBpcre_free_substring()\fR and
|
952 |
\fBpcre_free_substring_list()\fR can be used to free the memory returned by
|
953 |
a previous call of \fBpcre_get_substring()\fR or
|
954 |
\fBpcre_get_substring_list()\fR, respectively. They do nothing more than call
|
955 |
the function pointed to by \fBpcre_free\fR, which of course could be called
|
956 |
directly from a C program. However, PCRE is used in some situations where it is
|
957 |
linked via a special interface to another programming language which cannot use
|
958 |
\fBpcre_free\fR directly; it is for these cases that the functions are
|
959 |
provided.
|
960 |
|
961 |
.SH EXTRACTING CAPTURED SUBSTRINGS BY NAME
|
962 |
.rs
|
963 |
.sp
|
964 |
.B int pcre_copy_named_substring(const pcre *\fIcode\fR,
|
965 |
.ti +5n
|
966 |
.B const char *\fIsubject\fR, int *\fIovector\fR,
|
967 |
.ti +5n
|
968 |
.B int \fIstringcount\fR, const char *\fIstringname\fR,
|
969 |
.ti +5n
|
970 |
.B char *\fIbuffer\fR, int \fIbuffersize\fR);
|
971 |
.PP
|
972 |
.br
|
973 |
.B int pcre_get_stringnumber(const pcre *\fIcode\fR,
|
974 |
.ti +5n
|
975 |
.B const char *\fIname\fR);
|
976 |
.PP
|
977 |
.br
|
978 |
.B int pcre_get_named_substring(const pcre *\fIcode\fR,
|
979 |
.ti +5n
|
980 |
.B const char *\fIsubject\fR, int *\fIovector\fR,
|
981 |
.ti +5n
|
982 |
.B int \fIstringcount\fR, const char *\fIstringname\fR,
|
983 |
.ti +5n
|
984 |
.B const char **\fIstringptr\fR);
|
985 |
.PP
|
986 |
To extract a substring by name, you first have to find associated number. This
|
987 |
can be done by calling \fBpcre_get_stringnumber()\fR. The first argument is the
|
988 |
compiled pattern, and the second is the name. For example, for this pattern
|
989 |
|
990 |
ab(?<xxx>\\d+)...
|
991 |
|
992 |
the number of the subpattern called "xxx" is 1. Given the number, you can then
|
993 |
extract the substring directly, or use one of the functions described in the
|
994 |
previous section. For convenience, there are also two functions that do the
|
995 |
whole job.
|
996 |
|
997 |
Most of the arguments of \fIpcre_copy_named_substring()\fR and
|
998 |
\fIpcre_get_named_substring()\fR are the same as those for the functions that
|
999 |
extract by number, and so are not re-described here. There are just two
|
1000 |
differences.
|
1001 |
|
1002 |
First, instead of a substring number, a substring name is given. Second, there
|
1003 |
is an extra argument, given at the start, which is a pointer to the compiled
|
1004 |
pattern. This is needed in order to gain access to the name-to-number
|
1005 |
translation table.
|
1006 |
|
1007 |
These functions call \fBpcre_get_stringnumber()\fR, and if it succeeds, they
|
1008 |
then call \fIpcre_copy_substring()\fR or \fIpcre_get_substring()\fR, as
|
1009 |
appropriate.
|
1010 |
|
1011 |
.in 0
|
1012 |
Last updated: 03 February 2003
|
1013 |
.br
|
1014 |
Copyright (c) 1997-2003 University of Cambridge.
|