perlreguts.pod

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· POD 代码 · 共 888 行 · 第 1/3 页

=head1 NAME

perlreguts - Description of the Perl regular expression engine.

=head1 DESCRIPTION

This document is an attempt to shine some light on the guts of the regex
engine and how it works. The regex engine represents a significant chunk
of the perl codebase, but is relatively poorly understood. This document
is a meagre attempt at addressing this situation. It is derived from the
author's experience, comments in the source code, other papers on the
regex engine, feedback on the perl5-porters mail list, and no doubt other
places as well.

B<NOTICE!> It should be clearly understood that the behavior and
structures discussed in this represents the state of the engine as the
author understood it at the time of writing. It is B<NOT> an API
definition, it is purely an internals guide for those who want to hack
the regex engine, or understand how the regex engine works. Readers of
this document are expected to understand perl's regex syntax and its
usage in detail. If you want to learn about the basics of Perl's
regular expressions, see L<perlre>. And if you want to replace the
regex engine with your own see see L<perlreapi>.

=head1 OVERVIEW

=head2 A quick note on terms

There is some debate as to whether to say "regexp" or "regex". In this
document we will use the term "regex" unless there is a special reason
not to, in which case we will explain why.

When speaking about regexes we need to distinguish between their source
code form and their internal form. In this document we will use the term
"pattern" when we speak of their textual, source code form, and the term
"program" when we speak of their internal representation. These
correspond to the terms I<S-regex> and I<B-regex> that Mark Jason
Dominus employs in his paper on "Rx" ([1] in L</REFERENCES>).

=head2 What is a regular expression engine?

A regular expression engine is a program that takes a set of constraints
specified in a mini-language, and then applies those constraints to a
target string, and determines whether or not the string satisfies the
constraints. See L<perlre> for a full definition of the language.

In less grandiose terms, the first part of the job is to turn a pattern into
something the computer can efficiently use to find the matching point in
the string, and the second part is performing the search itself.

To do this we need to produce a program by parsing the text. We then
need to execute the program to find the point in the string that
matches. And we need to do the whole thing efficiently.

=head2 Structure of a Regexp Program

=head3 High Level

Although it is a bit confusing and some people object to the terminology, it
is worth taking a look at a comment that has
been in F<regexp.h> for years:

I<This is essentially a linear encoding of a nondeterministic
finite-state machine (aka syntax charts or "railroad normal form" in
parsing technology).>

The term "railroad normal form" is a bit esoteric, with "syntax
diagram/charts", or "railroad diagram/charts" being more common terms.
Nevertheless it provides a useful mental image of a regex program: each
node can be thought of as a unit of track, with a single entry and in
most cases a single exit point (there are pieces of track that fork, but
statistically not many), and the whole forms a layout with a
single entry and single exit point. The matching process can be thought
of as a car that moves along the track, with the particular route through
the system being determined by the character read at each possible
connector point. A car can fall off the track at any point but it may
only proceed as long as it matches the track.

Thus the pattern C</foo(?:\w+|\d+|\s+)bar/> can be thought of as the
following chart:

                      [start]
                         |
                       <foo>
                         |
                   +-----+-----+
                   |     |     |
                 <\w+> <\d+> <\s+>
                   |     |     |
                   +-----+-----+
                         |
                       <bar>
                         |
                       [end]

The truth of the matter is that perl's regular expressions these days are
much more complex than this kind of structure, but visualising it this way
can help when trying to get your bearings, and it matches the
current implementation pretty closely.

To be more precise, we will say that a regex program is an encoding
of a graph. Each node in the graph corresponds to part of
the original regex pattern, such as a literal string or a branch,
and has a pointer to the nodes representing the next component
to be matched. Since "node" and "opcode" already have other meanings in the
perl source, we will call the nodes in a regex program "regops".

The program is represented by an array of C<regnode> structures, one or
more of which represent a single regop of the program. Struct
C<regnode> is the smallest struct needed, and has a field structure which is
shared with all the other larger structures.

The "next" pointers of all regops except C<BRANCH> implement concatenation;
a "next" pointer with a C<BRANCH> on both ends of it is connecting two
alternatives.  [Here we have one of the subtle syntax dependencies: an
individual C<BRANCH> (as opposed to a collection of them) is never
concatenated with anything because of operator precedence.]

The operand of some types of regop is a literal string; for others,
it is a regop leading into a sub-program.  In particular, the operand
of a C<BRANCH> node is the first regop of the branch.

B<NOTE>: As the railroad metaphor suggests, this is B<not> a tree
structure:  the tail of the branch connects to the thing following the
set of C<BRANCH>es.  It is a like a single line of railway track that
splits as it goes into a station or railway yard and rejoins as it comes
out the other side.

=head3 Regops

The base structure of a regop is defined in F<regexp.h> as follows:

    struct regnode {
        U8  flags;    /* Various purposes, sometimes overridden */
        U8  type;     /* Opcode value as specified by regnodes.h */
        U16 next_off; /* Offset in size regnode */
    };

Other larger C<regnode>-like structures are defined in F<regcomp.h>. They
are almost like subclasses in that they have the same fields as
C<regnode>, with possibly additional fields following in
the structure, and in some cases the specific meaning (and name)
of some of base fields are overridden. The following is a more
complete description.

=over 4

=item C<regnode_1>

=item C<regnode_2>

C<regnode_1> structures have the same header, followed by a single
four-byte argument; C<regnode_2> structures contain two two-byte
arguments instead:

    regnode_1                U32 arg1;
    regnode_2                U16 arg1;  U16 arg2;

=item C<regnode_string>

C<regnode_string> structures, used for literal strings, follow the header
with a one-byte length and then the string data. Strings are padded on
the end with zero bytes so that the total length of the node is a
multiple of four bytes:

    regnode_string           char string[1];
                             U8 str_len; /* overrides flags */

=item C<regnode_charclass>

Character classes are represented by C<regnode_charclass> structures,
which have a four-byte argument and then a 32-byte (256-bit) bitmap
indicating which characters are included in the class.

    regnode_charclass        U32 arg1;
                             char bitmap[ANYOF_BITMAP_SIZE];

=item C<regnode_charclass_class>

There is also a larger form of a char class structure used to represent
POSIX char classes called C<regnode_charclass_class> which has an
additional 4-byte (32-bit) bitmap indicating which POSIX char classes
have been included.

    regnode_charclass_class  U32 arg1;
                             char bitmap[ANYOF_BITMAP_SIZE];
                             char classflags[ANYOF_CLASSBITMAP_SIZE];

=back

F<regnodes.h> defines an array called C<regarglen[]> which gives the size
of each opcode in units of C<size regnode> (4-byte). A macro is used
to calculate the size of an C<EXACT> node based on its C<str_len> field.

The regops are defined in F<regnodes.h> which is generated from
F<regcomp.sym> by F<regcomp.pl>. Currently the maximum possible number
of distinct regops is restricted to 256, with about a quarter already
used.

A set of macros makes accessing the fields
easier and more consistent. These include C<OP()>, which is used to determine
the type of a C<regnode>-like structure; C<NEXT_OFF()>, which is the offset to
the next node (more on this later); C<ARG()>, C<ARG1()>, C<ARG2()>, C<ARG_SET()>,
and equivalents for reading and setting the arguments; and C<STR_LEN()>,
C<STRING()> and C<OPERAND()> for manipulating strings and regop bearing
types.

=head3 What regop is next?

There are three distinct concepts of "next" in the regex engine, and
it is important to keep them clear.

=over 4

=item *

There is the "next regnode" from a given regnode, a value which is
rarely useful except that sometimes it matches up in terms of value
with one of the others, and that sometimes the code assumes this to
always be so.

=item *

There is the "next regop" from a given regop/regnode. This is the
regop physically located after the the current one, as determined by
the size of the current regop. This is often useful, such as when
dumping the structure we use this order to traverse. Sometimes the code
assumes that the "next regnode" is the same as the "next regop", or in
other words assumes that the sizeof a given regop type is always going
to be one regnode large.

=item *

There is the "regnext" from a given regop. This is the regop which
is reached by jumping forward by the value of C<NEXT_OFF()>,
or in a few cases for longer jumps by the C<arg1> field of the C<regnode_1>
structure. The subroutine C<regnext()> handles this transparently.
This is the logical successor of the node, which in some cases, like
that of the C<BRANCH> regop, has special meaning.

=back

=head1 Process Overview

Broadly speaking, performing a match of a string against a pattern
involves the following steps:

=over 5

=item A. Compilation

=over 5

=item 1. Parsing for size

=item 2. Parsing for construction

=item 3. Peep-hole optimisation and analysis

=back

=item B. Execution

=over 5

=item 4. Start position and no-match optimisations

=item 5. Program execution

=back

=back


Where these steps occur in the actual execution of a perl program is
determined by whether the pattern involves interpolating any string
variables. If interpolation occurs, then compilation happens at run time. If it
does not, then compilation is performed at compile time. (The C</o> modifier changes this,
as does C<qr//> to a certain extent.) The engine doesn't really care that
much.

=head2 Compilation

This code resides primarily in F<regcomp.c>, along with the header files
F<regcomp.h>, F<regexp.h> and F<regnodes.h>.

Compilation starts with C<pregcomp()>, which is mostly an initialisation
wrapper which farms work out to two other routines for the heavy lifting: the
first is C<reg()>, which is the start point for parsing; the second,
C<study_chunk()>, is responsible for optimisation.

Initialisation in C<pregcomp()> mostly involves the creation and data-filling
of a special structure, C<RExC_state_t> (defined in F<regcomp.c>).
Almost all internally-used routines in F<regcomp.h> take a pointer to one
of these structures as their first argument, with the name C<pRExC_state>.
This structure is used to store the compilation state and contains many