History log of /freebsd-10.3-release/lib/libc/regex/engine.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 296373 04-Mar-2016 marius

- Copy stable/10@296371 to releng/10.3 in preparation for 10.3-RC1
builds.
- Update newvers.sh to reflect RC1.
- Update __FreeBSD_version to reflect 10.3.
- Update default pkg(8) configuration to use the quarterly branch.

Approved by: re (implicit)

# 265726 09-May-2014 pfg

MFC r265202:
Remove some unreachable breaks in regex.

This is based on a much bigger cleanup done in Illumos.

Reference:
https://www.illumos.org/issues/2077


# 256281 10-Oct-2013 gjb

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation


# 197246 16-Sep-2009 dds

Fix an off-by-one error in the marking of the O_CH operator
following an OOR2 operator.

PR: 130504
MFC after: 2 weeks


# 197245 16-Sep-2009 dds

Add a couple of debugging statements.


# 169982 25-May-2007 delphij

Const'ify and ANSIfy the internal interfaces of regex(3).
This is the final change that makes libc to compile with
WERROR on my amd64 crashbox.


# 167222 05-Mar-2007 delphij

Only stop evaluation of a back reference if the match length is
zero and the recursion level is too deep.

Obtained from: OpenBSD


# 167216 05-Mar-2007 delphij

Avoid infinite recursion on:

echo "foo foo bar bar bar baz" | sed 's/\([^ ]*\)\( *\1\)*/\1/g'

Obtained from: OpenBSD via NetBSD (rev. 1.18)


# 165903 09-Jan-2007 imp

Per Regents of the University of Calfornia letter, remove advertising
clause.

# If I've done so improperly on a file, please let me know.


# 149180 17-Aug-2005 tjr

Fix a boundary condition error in slow() and fast() in multibyte locales:
we must allow the character beginning at "p" to be converted to a wide
character for the purposes of EOL processing and word-boundary matching.


# 139437 30-Dec-2004 dds

Plug memory leak.

PR: bin/75656
MFC after: 2 weeks


# 137959 21-Nov-2004 tjr

Fix computation of the 'n' argument to mbrtowc (through XMBRTOWC) to avoid
reading past 'stop' in various places when converting multibyte characters.
Reading too far caused truncation to not be detected when it should have
been, eventually causing regexec() to loop infinitely in with certain
combinations of patterns and strings in multibyte locales.

PR: 74020
MFC after: 4 weeks


# 132019 12-Jul-2004 tjr

Make regular expression matching aware of multibyte characters. The general
idea is that we perform multibyte->wide character conversion while parsing
and compiling, then convert byte sequences to wide characters when they're
needed for comparison and stepping through the string during execution.

As with tr(1), the main complication is to efficiently represent sets of
characters in bracket expressions. The old bitmap representation is replaced
by a bitmap for the first 256 characters combined with a vector of individual
wide characters, a vector of character ranges (for [A-Z] etc.), and a vector
of character classes (for [[:alpha:]] etc.).

One other point of interest is that although the Boyer-Moore algorithm had
to be disabled in the general multibyte case, it is still enabled for UTF-8
because of its self-synchronizing nature. This greatly speeds up matching
by reducing the number of multibyte conversions that need to be done.


# 111010 16-Feb-2003 nectar

Eliminate 61 warnings emitted at WARNS=2 (leaving 53 to go).
Only warnings that could be fixed without changing the generated object
code and without restructuring the source code have been handled.

Reviewed by: /sbin/md5


# 92986 22-Mar-2002 obrien

Fix the style of the SCM ID's.
I believe have made all of libc .c's as consistent as possible.


# 92905 21-Mar-2002 obrien

Remove __P() usage.


# 92889 21-Mar-2002 obrien

Remove 'register' keyword.


# 62854 09-Jul-2000 dcs

Since g->moffset points to the _maximum_ offset at which the must
string may be found (from the beginning of the pattern), the point
at which must is found minus that offset may actually point to some
place before the start of the text.

In that case, make start = start.

Alternatively, this could be tested for in the preceding if, but it
did not occur to me. :-)

Caught by: regex(3) test code


# 62754 07-Jul-2000 dcs

Deal with the signed/unsigned chars issue in a more proper manner. We
use a CHAR_MIN-based array, like elsewhere in the code.

Remove a number of unused variables (some due to the above change, one
that was left after a number of optimizing steps through the source).

Brucified by: bde


# 62391 02-Jul-2000 dcs

Enhance the optimization provided by pre-matching. Fix style bugs with
previous commits.

At the time we search the pattern for the "must" string, we now compute
the longest offset from the beginning of the pattern at which the must
string might be found. If that offset is found to be infinite (through
use of "+" or "*"), we set it to -1 to disable the heuristics applied
later.

After we are done with pre-matching, we use that offset and the point in
the text at which the must string was found to compute the earliest
point at which the pattern might be found.

Special care should be taken here. The variable "start" is passed to the
automata-processing functions fast() and slow() to indicate the point in
the text at which they should start working from. The real beginning of
the text is passed in a struct match variable m, which is used to check
for anchors. That variable, though, is initialized with "start", so we
must not adjust "start" before "m" is properly initialized.

Simple tests showed a speed increase from 100% to 400%, but they were
biased in that regexec() was called for the whole file instead of line
by line, and parenthized subexpressions were not searched for.

This change adds a single integer to the size of the "guts" structure,
and does not change the ABI.

Further improvements possible:

Since the speed increase observed here is so huge, one intuitive
optimization would be to introduce a bias in the function that computes
the "must" string so as to prefer a smaller string with a finite offset
over a larger one with an infinite offset. Tests have shown this to be a
bad idea, though, as the cost of false pre-matches far outweights the
benefits of a must offset, even in biased situations.

A number of other improvements suggest themselves, though:

* identify the cases where the pattern is identical to the must
string, and avoid entering fast() and slow() in these cases.

* compute the maximum offset from the must string to the end of
the pattern, and use that to set the point at which fast() and
slow() should give up trying to find a match, and return then
return to pre-matching.

* return all the way to pre-matching if a "match" was found and
later invalidated by back reference processing. Since back
references are evil and should be avoided anyway, this is of
little use.


# 62232 29-Jun-2000 dcs

Add Boyler-Moore algorithm to pre-matching test.

The BM algorithm works by scanning the pattern from right to left,
and jumping as many characters as viable based on the text's mismatched
character and the pattern's already matched suffix.

This typically enable us to test only a fraction of the text's characters,
but has a worse performance than the straight-forward method for small
patterns. Because of this, the BM algorithm will only be used if the
pattern size is at least 4 characters.

Notice that this pre-matching is done on the largest substring of the
regular expression that _must_ be present on the text for a succesful
match to be possible at all.

For instance, "(xyzzy|grues)" will yield a null "must" substring, and,
therefore, not benefit from the BM algorithm at all. Because of the
lack of intelligence of the algorithm that finds the "must" string,
things like "charjump|matchjump" will also yield a null string. To
optimize that, "(char|match)jump" should be used.

The setup time (at regcomp()) for the BM algorithm will most likely
outweight any benefits for one-time matches. Given the slow regex(3)
we have, this is unlikely to be even perceptible, though.

The size of a regex_t structure is increased by 2*sizeof(char*) +
256*sizeof(int) + strlen(must)*sizeof(int). This is all inside the
regex_t's "guts", which is allocated dynamically by regcomp(). If
allocation of either of the two tables fail, the other one is freed.
In this case, the straight-forward algorithm is used for pre-matching.

Tests exercising the code path affected have shown a speed increase of
50% for "must" strings of length four or five.

API and ABI remain unchanged by this commit.

The patch submitted on the PR was not used, as it was non-functional.

PR: 14342


# 17508 11-Aug-1996 ache

Use locale for character classes instead of hardcoded values
Misc 8bit cleanup


# 17141 12-Jul-1996 jkh

General -Wall warning cleanup, part I.
Submitted-By: Kent Vander Velden <graphix@iastate.edu>


# 11664 22-Oct-1995 phk

More cleanup.
Uhm, I also forgot: I took "EXTRA_SANITY" out of malloc.c


# 8870 30-May-1995 rgrimes

Remove trailing whitespace.


# 1574 27-May-1994 rgrimes

This commit was generated by cvs2svn to compensate for changes in r1573,
which included commits to RCS files with non-trunk default branches.


# 1573 27-May-1994 rgrimes

BSD 4.4 Lite Lib Sources