postgresql/src/backend/regex/regc_cvec.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

139 lines
3.9 KiB
C
Raw Normal View History

/*
* Utility functions for handling cvecs
* This file is #included by regcomp.c.
*
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
*
* Development of this software was funded, in part, by Cray Research Inc.,
* UUNET Communications Services Inc., Sun Microsystems Inc., and Scriptics
* Corporation, none of whom are responsible for the results. The author
* thanks all of them.
*
* Redistribution and use in source and binary forms -- with or without
* modification -- are permitted for any purpose, provided that
* redistributions in source form retain this entire copyright notice and
* indicate the origin and nature of any modifications.
*
* I'd appreciate being given credit for this package in the documentation
* of software which uses it, but that is not a requirement.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* HENRY SPENCER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
2010-09-20 22:08:53 +02:00
* src/backend/regex/regc_cvec.c
*
*/
/*
* Notes:
Make locale-dependent regex character classes work for large char codes. Previously, we failed to recognize Unicode characters above U+7FF as being members of locale-dependent character classes such as [[:alpha:]]. (Actually, the same problem occurs for large pg_wchar values in any multibyte encoding, but UTF8 is the only case people have actually complained about.) It's impractical to get Spencer's original code to handle character classes or ranges containing many thousands of characters, because it insists on considering each member character individually at regex compile time, whether or not the character will ever be of interest at run time. To fix, choose a cutoff point MAX_SIMPLE_CHR below which we process characters individually as before, and deal with entire ranges or classes as single entities above that. We can actually make things cheaper than before for chars below the cutoff, because the color map can now be a simple linear array for those chars, rather than the multilevel tree structure Spencer designed. It's more expensive than before for chars above the cutoff, because we must do a binary search in a list of high chars and char ranges used in the regex pattern, plus call iswalpha() and friends for each locale-dependent character class used in the pattern. However, multibyte encodings are normally designed to give smaller codes to popular characters, so that we can expect that the slow path will be taken relatively infrequently. In any case, the speed penalty appears minor except when we have to apply iswalpha() etc. to high character codes at runtime --- and the previous coding gave wrong answers for those cases, so whether it was faster is moot. Tom Lane, reviewed by Heikki Linnakangas Discussion: <15563.1471913698@sss.pgh.pa.us>
2016-09-05 23:06:29 +02:00
* Only (selected) functions in _this_ file should treat the chr arrays
* of a cvec as non-constant.
*/
/*
* newcvec - allocate a new cvec
*/
static struct cvec *
newcvec(int nchrs, /* to hold this many chrs... */
int nranges) /* ... and this many ranges */
{
size_t nc = (size_t) nchrs + (size_t) nranges * 2;
size_t n = sizeof(struct cvec) + nc * sizeof(chr);
struct cvec *cv = (struct cvec *) MALLOC(n);
2003-08-04 02:43:34 +02:00
if (cv == NULL)
return NULL;
cv->chrspace = nchrs;
cv->chrs = (chr *) (((char *) cv) + sizeof(struct cvec));
cv->ranges = cv->chrs + nchrs;
cv->rangespace = nranges;
return clearcvec(cv);
}
/*
* clearcvec - clear a possibly-new cvec
* Returns pointer as convenience.
*/
static struct cvec *
clearcvec(struct cvec *cv)
{
assert(cv != NULL);
cv->nchrs = 0;
cv->nranges = 0;
Make locale-dependent regex character classes work for large char codes. Previously, we failed to recognize Unicode characters above U+7FF as being members of locale-dependent character classes such as [[:alpha:]]. (Actually, the same problem occurs for large pg_wchar values in any multibyte encoding, but UTF8 is the only case people have actually complained about.) It's impractical to get Spencer's original code to handle character classes or ranges containing many thousands of characters, because it insists on considering each member character individually at regex compile time, whether or not the character will ever be of interest at run time. To fix, choose a cutoff point MAX_SIMPLE_CHR below which we process characters individually as before, and deal with entire ranges or classes as single entities above that. We can actually make things cheaper than before for chars below the cutoff, because the color map can now be a simple linear array for those chars, rather than the multilevel tree structure Spencer designed. It's more expensive than before for chars above the cutoff, because we must do a binary search in a list of high chars and char ranges used in the regex pattern, plus call iswalpha() and friends for each locale-dependent character class used in the pattern. However, multibyte encodings are normally designed to give smaller codes to popular characters, so that we can expect that the slow path will be taken relatively infrequently. In any case, the speed penalty appears minor except when we have to apply iswalpha() etc. to high character codes at runtime --- and the previous coding gave wrong answers for those cases, so whether it was faster is moot. Tom Lane, reviewed by Heikki Linnakangas Discussion: <15563.1471913698@sss.pgh.pa.us>
2016-09-05 23:06:29 +02:00
cv->cclasscode = -1;
return cv;
}
/*
* addchr - add a chr to a cvec
*/
static void
addchr(struct cvec *cv, /* character vector */
chr c) /* character to add */
{
assert(cv->nchrs < cv->chrspace);
cv->chrs[cv->nchrs++] = c;
}
/*
* addrange - add a range to a cvec
*/
static void
addrange(struct cvec *cv, /* character vector */
chr from, /* first character of range */
chr to) /* last character of range */
{
assert(cv->nranges < cv->rangespace);
cv->ranges[cv->nranges * 2] = from;
cv->ranges[cv->nranges * 2 + 1] = to;
cv->nranges++;
}
/*
* getcvec - get a transient cvec, initialized to empty
*
* The returned cvec is valid only until the next call of getcvec, which
* typically will recycle the space. Callers should *not* free the cvec
* explicitly; it will be cleaned up when the struct vars is destroyed.
*
* This is typically used while interpreting bracket expressions. In that
* usage the cvec is only needed momentarily until we build arcs from it,
* so transientness is a convenient behavior.
*/
static struct cvec *
getcvec(struct vars *v, /* context */
int nchrs, /* to hold this many chrs... */
int nranges) /* ... and this many ranges */
{
/* recycle existing transient cvec if large enough */
if (v->cv != NULL && nchrs <= v->cv->chrspace &&
nranges <= v->cv->rangespace)
return clearcvec(v->cv);
2003-08-04 02:43:34 +02:00
/* nope, make a new one */
if (v->cv != NULL)
freecvec(v->cv);
v->cv = newcvec(nchrs, nranges);
if (v->cv == NULL)
ERR(REG_ESPACE);
2003-08-04 02:43:34 +02:00
return v->cv;
}
/*
* freecvec - free a cvec
*/
static void
freecvec(struct cvec *cv)
{
FREE(cv);
}