2003-08-04 02:43:34 +02:00
|
|
|
/*
|
2003-02-05 18:41:33 +01:00
|
|
|
* regc_locale.c --
|
|
|
|
*
|
|
|
|
* This file contains locale-specific regexp routines.
|
|
|
|
* This file is #included by regcomp.c.
|
|
|
|
*
|
|
|
|
* Copyright (c) 1998 by Scriptics Corporation.
|
|
|
|
*
|
|
|
|
* This software is copyrighted by the Regents of the University of
|
|
|
|
* California, Sun Microsystems, Inc., Scriptics Corporation, ActiveState
|
|
|
|
* Corporation and other parties. The following terms apply to all files
|
|
|
|
* associated with the software unless explicitly disclaimed in
|
|
|
|
* individual files.
|
2003-08-04 02:43:34 +02:00
|
|
|
*
|
2003-02-05 18:41:33 +01:00
|
|
|
* The authors hereby grant permission to use, copy, modify, distribute,
|
|
|
|
* and license this software and its documentation for any purpose, provided
|
|
|
|
* that existing copyright notices are retained in all copies and that this
|
|
|
|
* notice is included verbatim in any distributions. No written agreement,
|
|
|
|
* license, or royalty fee is required for any of the authorized uses.
|
|
|
|
* Modifications to this software may be copyrighted by their authors
|
|
|
|
* and need not follow the licensing terms described here, provided that
|
|
|
|
* the new terms are clearly indicated on the first page of each file where
|
|
|
|
* they apply.
|
2003-08-04 02:43:34 +02:00
|
|
|
*
|
2003-02-05 18:41:33 +01:00
|
|
|
* IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY
|
|
|
|
* FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
|
|
|
|
* ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY
|
|
|
|
* DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
2003-08-04 02:43:34 +02:00
|
|
|
*
|
2003-02-05 18:41:33 +01:00
|
|
|
* THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,
|
|
|
|
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
|
2014-05-06 18:12:18 +02:00
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE
|
2003-02-05 18:41:33 +01:00
|
|
|
* IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE
|
|
|
|
* NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
|
|
|
|
* MODIFICATIONS.
|
2003-08-04 02:43:34 +02:00
|
|
|
*
|
2003-02-05 18:41:33 +01:00
|
|
|
* GOVERNMENT USE: If you are acquiring this software on behalf of the
|
|
|
|
* U.S. government, the Government shall have only "Restricted Rights"
|
2003-08-04 02:43:34 +02:00
|
|
|
* in the software and related documentation as defined in the Federal
|
2014-05-06 18:12:18 +02:00
|
|
|
* Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2). If you
|
2003-02-05 18:41:33 +01:00
|
|
|
* are acquiring the software on behalf of the Department of Defense, the
|
|
|
|
* software shall be classified as "Commercial Computer Software" and the
|
|
|
|
* Government shall have only "Restricted Rights" as defined in Clause
|
|
|
|
* 252.227-7013 (c) (1) of DFARs. Notwithstanding the foregoing, the
|
|
|
|
* authors grant the U.S. Government and others acting in its behalf
|
|
|
|
* permission to use and distribute the software in accordance with the
|
2003-08-04 02:43:34 +02:00
|
|
|
* terms specified in this license.
|
2003-02-05 18:41:33 +01:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/regex/regc_locale.c
|
2003-02-05 18:41:33 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* ASCII character-name table */
|
|
|
|
|
2008-02-14 18:33:37 +01:00
|
|
|
static const struct cname
|
2003-08-04 02:43:34 +02:00
|
|
|
{
|
2008-02-14 18:33:37 +01:00
|
|
|
const char *name;
|
|
|
|
const char code;
|
2017-06-21 20:39:04 +02:00
|
|
|
} cnames[] =
|
2003-08-04 02:43:34 +02:00
|
|
|
|
|
|
|
{
|
|
|
|
{
|
|
|
|
"NUL", '\0'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"SOH", '\001'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"STX", '\002'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"ETX", '\003'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"EOT", '\004'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"ENQ", '\005'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"ACK", '\006'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"BEL", '\007'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"alert", '\007'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"BS", '\010'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"backspace", '\b'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"HT", '\011'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"tab", '\t'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"LF", '\012'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"newline", '\n'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"VT", '\013'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"vertical-tab", '\v'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"FF", '\014'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"form-feed", '\f'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"CR", '\015'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"carriage-return", '\r'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"SO", '\016'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"SI", '\017'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"DLE", '\020'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"DC1", '\021'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"DC2", '\022'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"DC3", '\023'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"DC4", '\024'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"NAK", '\025'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"SYN", '\026'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"ETB", '\027'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"CAN", '\030'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"EM", '\031'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"SUB", '\032'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"ESC", '\033'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"IS4", '\034'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"FS", '\034'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"IS3", '\035'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"GS", '\035'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"IS2", '\036'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"RS", '\036'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"IS1", '\037'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"US", '\037'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"space", ' '
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"exclamation-mark", '!'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"quotation-mark", '"'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"number-sign", '#'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"dollar-sign", '$'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"percent-sign", '%'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"ampersand", '&'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"apostrophe", '\''
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"left-parenthesis", '('
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"right-parenthesis", ')'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"asterisk", '*'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"plus-sign", '+'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"comma", ','
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"hyphen", '-'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"hyphen-minus", '-'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"period", '.'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"full-stop", '.'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"slash", '/'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"solidus", '/'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"zero", '0'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"one", '1'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"two", '2'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"three", '3'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"four", '4'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"five", '5'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"six", '6'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"seven", '7'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"eight", '8'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"nine", '9'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"colon", ':'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"semicolon", ';'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"less-than-sign", '<'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"equals-sign", '='
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"greater-than-sign", '>'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"question-mark", '?'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"commercial-at", '@'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"left-square-bracket", '['
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"backslash", '\\'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"reverse-solidus", '\\'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"right-square-bracket", ']'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"circumflex", '^'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"circumflex-accent", '^'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"underscore", '_'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"low-line", '_'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"grave-accent", '`'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"left-brace", '{'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"left-curly-bracket", '{'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"vertical-line", '|'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"right-brace", '}'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"right-curly-bracket", '}'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"tilde", '~'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"DEL", '\177'
|
|
|
|
},
|
|
|
|
{
|
|
|
|
NULL, 0
|
|
|
|
}
|
2003-02-05 18:41:33 +01:00
|
|
|
};
|
|
|
|
|
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
|
|
|
/*
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
* The following array defines the valid character class names.
|
|
|
|
* The entries must match enum char_classes in regguts.h.
|
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
|
|
|
*/
|
|
|
|
static const char *const classNames[NUM_CCLASSES + 1] = {
|
|
|
|
"alnum", "alpha", "ascii", "blank", "cntrl", "digit", "graph",
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
"lower", "print", "punct", "space", "upper", "xdigit", "word",
|
|
|
|
NULL
|
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
|
|
|
};
|
2009-12-01 22:00:24 +01:00
|
|
|
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
/*
|
|
|
|
* We do not use the hard-wired Unicode classification tables that Tcl does.
|
|
|
|
* This is because (a) we need to deal with other encodings besides Unicode,
|
|
|
|
* and (b) we want to track the behavior of the libc locale routines as
|
|
|
|
* closely as possible. For example, it wouldn't be unreasonable for a
|
|
|
|
* locale to not consider every Unicode letter as a letter. So we build
|
|
|
|
* character classification cvecs by asking libc, even for Unicode.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2003-02-05 18:41:33 +01:00
|
|
|
/*
|
2016-08-19 18:51:02 +02:00
|
|
|
* element - map collating-element name to chr
|
2003-02-05 18:41:33 +01:00
|
|
|
*/
|
2016-08-19 18:51:02 +02:00
|
|
|
static chr
|
2017-06-21 20:39:04 +02:00
|
|
|
element(struct vars *v, /* context */
|
2008-02-14 18:33:37 +01:00
|
|
|
const chr *startp, /* points to start of name */
|
|
|
|
const chr *endp) /* points just past end of name */
|
2003-02-05 18:41:33 +01:00
|
|
|
{
|
2008-02-14 18:33:37 +01:00
|
|
|
const struct cname *cn;
|
2003-08-04 02:43:34 +02:00
|
|
|
size_t len;
|
|
|
|
|
|
|
|
/* generic: one-chr names stand for themselves */
|
|
|
|
assert(startp < endp);
|
|
|
|
len = endp - startp;
|
|
|
|
if (len == 1)
|
|
|
|
return *startp;
|
|
|
|
|
|
|
|
NOTE(REG_ULOCALE);
|
|
|
|
|
|
|
|
/* search table */
|
|
|
|
for (cn = cnames; cn->name != NULL; cn++)
|
|
|
|
{
|
|
|
|
if (strlen(cn->name) == len &&
|
|
|
|
pg_char_and_wchar_strncmp(cn->name, startp, len) == 0)
|
|
|
|
{
|
|
|
|
break; /* NOTE BREAK OUT */
|
|
|
|
}
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
if (cn->name != NULL)
|
|
|
|
return CHR(cn->code);
|
|
|
|
|
|
|
|
/* couldn't find it */
|
|
|
|
ERR(REG_ECOLLATE);
|
|
|
|
return 0;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* range - supply cvec for a range, including legality check
|
|
|
|
*/
|
|
|
|
static struct cvec *
|
2017-06-21 20:39:04 +02:00
|
|
|
range(struct vars *v, /* context */
|
2016-08-19 18:51:02 +02:00
|
|
|
chr a, /* range start */
|
|
|
|
chr b, /* range end, might equal a */
|
2003-02-05 18:41:33 +01:00
|
|
|
int cases) /* case-independent? */
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
int nchrs;
|
|
|
|
struct cvec *cv;
|
2016-08-19 18:51:02 +02:00
|
|
|
chr c,
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
cc;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
|
|
|
if (a != b && !before(a, b))
|
|
|
|
{
|
|
|
|
ERR(REG_ERANGE);
|
|
|
|
return NULL;
|
|
|
|
}
|
2003-02-05 18:41:33 +01:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
if (!cases)
|
|
|
|
{ /* easy version */
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 0, 1);
|
2003-08-04 02:43:34 +02:00
|
|
|
NOERRN();
|
|
|
|
addrange(cv, a, b);
|
|
|
|
return cv;
|
|
|
|
}
|
2003-02-05 18:41:33 +01:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* When case-independent, it's hard to decide when cvec ranges are usable,
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
* so for now at least, we won't try. We use a range for the originally
|
|
|
|
* specified chrs and then add on any case-equivalents that are outside
|
|
|
|
* that range as individual chrs.
|
|
|
|
*
|
|
|
|
* To ensure sane behavior if someone specifies a very large range, limit
|
|
|
|
* the allocation size to 100000 chrs (arbitrary) and check for overrun
|
|
|
|
* inside the loop below.
|
2003-08-04 02:43:34 +02:00
|
|
|
*/
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
nchrs = b - a + 1;
|
|
|
|
if (nchrs <= 0 || nchrs > 100000)
|
|
|
|
nchrs = 100000;
|
2003-02-05 18:41:33 +01:00
|
|
|
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
cv = getcvec(v, nchrs, 1);
|
2003-08-04 02:43:34 +02:00
|
|
|
NOERRN();
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
addrange(cv, a, b);
|
2003-02-05 18:41:33 +01:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
for (c = a; c <= b; c++)
|
|
|
|
{
|
2016-08-19 18:51:02 +02:00
|
|
|
cc = pg_wc_tolower(c);
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
if (cc != c &&
|
|
|
|
(before(cc, a) || before(b, cc)))
|
|
|
|
{
|
|
|
|
if (cv->nchrs >= cv->chrspace)
|
|
|
|
{
|
|
|
|
ERR(REG_ETOOBIG);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
addchr(cv, cc);
|
|
|
|
}
|
2016-08-19 18:51:02 +02:00
|
|
|
cc = pg_wc_toupper(c);
|
Fix some regex issues with out-of-range characters and large char ranges.
Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a
bad choice because it is outside the range of type "celt" (int32).
Characters approaching that limit could lead to infinite loops in logic
such as "for (c = a; c <= b; c++)" where c is of type celt but the
range bounds are chr. Such loops will work safely only if CHR_MAX+1
is representable in celt, since c must advance to beyond b before the
loop will exit.
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.
It's highly unlikely that Unicode will ever assign codes that high, and
none of our other backend encodings need characters beyond that either.
In addition to modifying the macro, we have to explicitly enforce character
range restrictions on the values of \u, \U, and \x escape sequences, else
the limit is trivially bypassed.
Also, the code for expanding case-independent character ranges in bracket
expressions had a potential integer overflow in its calculation of the
number of characters it could generate, which could lead to allocating too
small a character vector and then overwriting memory. An attacker with the
ability to supply arbitrary regex patterns could easily cause transient DOS
via server crashes, and the possibility for privilege escalation has not
been ruled out.
Quite aside from the integer-overflow problem, the range expansion code was
unnecessarily inefficient in that it always produced a result consisting of
individual characters, abandoning the knowledge that we had a range to
start with. If the input range is large, this requires excessive memory.
Change it so that the original range is reported as-is, and then we add on
any case-equivalent characters that are outside that range. With this
approach, we can bound the number of individual characters allowed without
sacrificing much. This patch allows at most 100000 individual characters,
which I believe to be more than the number of case pairs existing in
Unicode, so that the restriction will never be hit in practice.
It's still possible for range() to take awhile given a large character code
range, so also add statement-cancel detection to its loop. The downstream
function dovec() also lacked cancel detection, and could take a long time
given a large output from range().
Per fuzz testing by Greg Stark. Back-patch to all supported branches.
Security: CVE-2016-0773
2016-02-08 16:25:40 +01:00
|
|
|
if (cc != c &&
|
|
|
|
(before(cc, a) || before(b, cc)))
|
|
|
|
{
|
|
|
|
if (cv->nchrs >= cv->chrspace)
|
|
|
|
{
|
|
|
|
ERR(REG_ETOOBIG);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
addchr(cv, cc);
|
|
|
|
}
|
Redesign interrupt/cancel API for regex engine.
Previously, a PostgreSQL-specific callback checked by the regex engine
had a way to trigger a special error code REG_CANCEL if it detected that
the next call to CHECK_FOR_INTERRUPTS() would certainly throw via
ereport().
A later proposed bugfix aims to move some complex logic out of signal
handlers, so that it won't run until the next CHECK_FOR_INTERRUPTS(),
which makes the above design impossible unless we split
CHECK_FOR_INTERRUPTS() into two phases, one to run logic and another to
ereport(). We may develop such a system in the future, but for the
regex code it is no longer necessary.
An earlier commit moved regex memory management over to our
MemoryContext system. Given that the purpose of the two-phase interrupt
checking was to free memory before throwing, something we don't need to
worry about anymore, it seems simpler to inject CHECK_FOR_INTERRUPTS()
directly into cancelation points, and just let it throw.
Since the plan is to keep PostgreSQL-specific concerns separate from the
main regex engine code (with a view to bein able to stay in sync with
other projects), do this with a new macro INTERRUPT(), customizable in
regcustom.h and defaulting to nothing.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CA%2BhUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO%3DnEYKSg%40mail.gmail.com
2023-04-08 11:57:46 +02:00
|
|
|
INTERRUPT(v->re);
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
return cv;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2016-08-19 18:51:02 +02:00
|
|
|
* before - is chr x before chr y, for purposes of range legality?
|
2003-02-05 18:41:33 +01:00
|
|
|
*/
|
2003-08-04 02:43:34 +02:00
|
|
|
static int /* predicate */
|
2016-08-19 18:51:02 +02:00
|
|
|
before(chr x, chr y)
|
2003-02-05 18:41:33 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
if (x < y)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* eclass - supply cvec for an equivalence class
|
|
|
|
* Must include case counterparts on request.
|
|
|
|
*/
|
|
|
|
static struct cvec *
|
2017-06-21 20:39:04 +02:00
|
|
|
eclass(struct vars *v, /* context */
|
2016-08-19 18:51:02 +02:00
|
|
|
chr c, /* Collating element representing the
|
2003-08-04 02:43:34 +02:00
|
|
|
* equivalence class. */
|
2003-02-05 18:41:33 +01:00
|
|
|
int cases) /* all cases? */
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
struct cvec *cv;
|
|
|
|
|
|
|
|
/* crude fake equivalence class for testing */
|
|
|
|
if ((v->cflags & REG_FAKE) && c == 'x')
|
|
|
|
{
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 4, 0);
|
2016-08-19 18:51:02 +02:00
|
|
|
addchr(cv, CHR('x'));
|
|
|
|
addchr(cv, CHR('y'));
|
2003-08-04 02:43:34 +02:00
|
|
|
if (cases)
|
|
|
|
{
|
2016-08-19 18:51:02 +02:00
|
|
|
addchr(cv, CHR('X'));
|
|
|
|
addchr(cv, CHR('Y'));
|
2003-08-04 02:43:34 +02:00
|
|
|
}
|
|
|
|
return cv;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
|
|
|
|
/* otherwise, none */
|
|
|
|
if (cases)
|
|
|
|
return allcases(v, c);
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 1, 0);
|
2003-08-04 02:43:34 +02:00
|
|
|
assert(cv != NULL);
|
2016-08-19 18:51:02 +02:00
|
|
|
addchr(cv, c);
|
2003-02-05 18:41:33 +01:00
|
|
|
return cv;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
* lookupcclass - lookup a character class identified by name
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
*
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
* On failure, sets an error code in *v; the result is then garbage.
|
2003-02-05 18:41:33 +01:00
|
|
|
*/
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
static enum char_classes
|
|
|
|
lookupcclass(struct vars *v, /* context (for returning errors) */
|
|
|
|
const chr *startp, /* where the name starts */
|
|
|
|
const chr *endp) /* just past the end of the name */
|
2003-02-05 18:41:33 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
size_t len;
|
2017-06-21 20:39:04 +02:00
|
|
|
const char *const *namePtr;
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
int i;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Map the name to the corresponding enumerated value.
|
|
|
|
*/
|
|
|
|
len = endp - startp;
|
|
|
|
for (namePtr = classNames, i = 0; *namePtr != NULL; namePtr++, i++)
|
|
|
|
{
|
|
|
|
if (strlen(*namePtr) == len &&
|
|
|
|
pg_char_and_wchar_strncmp(*namePtr, startp, len) == 0)
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
return (enum char_classes) i;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
ERR(REG_ECTYPE);
|
|
|
|
return (enum char_classes) 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* cclasscvec - supply cvec for a character class
|
|
|
|
*
|
|
|
|
* Must include case counterparts if "cases" is true.
|
|
|
|
*
|
|
|
|
* The returned cvec might be either a transient cvec gotten from getcvec(),
|
|
|
|
* or a permanently cached one from pg_ctype_get_cache(). This is okay
|
|
|
|
* because callers are not supposed to explicitly free the result either way.
|
|
|
|
*/
|
|
|
|
static struct cvec *
|
|
|
|
cclasscvec(struct vars *v, /* context */
|
|
|
|
enum char_classes cclasscode, /* class to build a cvec for */
|
|
|
|
int cases) /* case-independent? */
|
|
|
|
{
|
|
|
|
struct cvec *cv = NULL;
|
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
/*
|
|
|
|
* Remap lower and upper to alpha if the match is case insensitive.
|
|
|
|
*/
|
2003-02-05 18:41:33 +01:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
if (cases &&
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
(cclasscode == CC_LOWER ||
|
|
|
|
cclasscode == CC_UPPER))
|
|
|
|
cclasscode = CC_ALPHA;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
|
|
|
/*
|
2012-06-10 21:20:04 +02:00
|
|
|
* Now compute the character class contents. For classes that are based
|
|
|
|
* on the behavior of a <wctype.h> or <ctype.h> function, we use
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
* pg_ctype_get_cache so that we can cache the results. Other classes
|
|
|
|
* have definitions that are hard-wired here, and for those we just
|
|
|
|
* construct a transient cvec on the fly.
|
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
|
|
|
*
|
|
|
|
* NB: keep this code in sync with cclass_column_index(), below.
|
2003-08-04 02:43:34 +02:00
|
|
|
*/
|
|
|
|
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
switch (cclasscode)
|
2003-08-04 02:43:34 +02:00
|
|
|
{
|
|
|
|
case CC_PRINT:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isprint, cclasscode);
|
2003-09-29 02:21:58 +02:00
|
|
|
break;
|
2003-08-04 02:43:34 +02:00
|
|
|
case CC_ALNUM:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isalnum, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_ALPHA:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isalpha, cclasscode);
|
|
|
|
break;
|
|
|
|
case CC_WORD:
|
|
|
|
cv = pg_ctype_get_cache(pg_wc_isword, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_ASCII:
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
/* hard-wired meaning */
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 0, 1);
|
2003-08-04 02:43:34 +02:00
|
|
|
if (cv)
|
|
|
|
addrange(cv, 0, 0x7f);
|
|
|
|
break;
|
|
|
|
case CC_BLANK:
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
/* hard-wired meaning */
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 2, 0);
|
2003-08-04 02:43:34 +02:00
|
|
|
addchr(cv, '\t');
|
|
|
|
addchr(cv, ' ');
|
|
|
|
break;
|
|
|
|
case CC_CNTRL:
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
/* hard-wired meaning */
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 0, 2);
|
2003-08-04 02:43:34 +02:00
|
|
|
addrange(cv, 0x0, 0x1f);
|
|
|
|
addrange(cv, 0x7f, 0x9f);
|
|
|
|
break;
|
|
|
|
case CC_DIGIT:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isdigit, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_PUNCT:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_ispunct, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_XDIGIT:
|
2012-06-10 21:20:04 +02:00
|
|
|
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
/*
|
|
|
|
* It's not clear how to define this in non-western locales, and
|
2012-06-10 21:20:04 +02:00
|
|
|
* even less clear that there's any particular use in trying. So
|
|
|
|
* just hard-wire the meaning.
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
*/
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 0, 3);
|
2003-08-04 02:43:34 +02:00
|
|
|
if (cv)
|
|
|
|
{
|
|
|
|
addrange(cv, '0', '9');
|
|
|
|
addrange(cv, 'a', 'f');
|
|
|
|
addrange(cv, 'A', 'F');
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case CC_SPACE:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isspace, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_LOWER:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_islower, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_UPPER:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isupper, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
|
|
|
case CC_GRAPH:
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
cv = pg_ctype_get_cache(pg_wc_isgraph, cclasscode);
|
2003-08-04 02:43:34 +02:00
|
|
|
break;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
Add caching of ctype.h/wctype.h results in regc_locale.c.
While this doesn't save a huge amount of runtime, it still seems worth
doing, especially since I realized that the data copying I did in my first
draft was quite unnecessary. In this version, once we have the results
cached, getting them back for re-use is really very cheap.
Also, remove the hard-wired limitation to not consider wctype.h results for
character codes above 255. It turns out that we can't push the limit as
far up as I'd originally hoped, because the regex colormap code is not
efficient enough to cope very well with character classes containing many
thousand letters, which a Unicode locale is entirely capable of producing.
Still, we can push it up to U+7FF (which I chose as the limit of 2-byte
UTF8 characters), which will at least make Eastern Europeans happy pending
a better solution. Thus, this commit resolves the specific complaint in
bug #6457, but not the more general issue that letters of non-western
alphabets are mostly not recognized as matching [[:alpha:]].
2012-02-20 03:01:13 +01:00
|
|
|
|
|
|
|
/* If cv is NULL now, the reason must be "out of memory" */
|
2003-08-04 02:43:34 +02:00
|
|
|
if (cv == NULL)
|
|
|
|
ERR(REG_ESPACE);
|
|
|
|
return cv;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* cclass_column_index - get appropriate high colormap column index for chr
|
|
|
|
*/
|
|
|
|
static int
|
2017-06-21 20:39:04 +02:00
|
|
|
cclass_column_index(struct colormap *cm, chr c)
|
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
|
|
|
{
|
|
|
|
int colnum = 0;
|
|
|
|
|
|
|
|
/* Shouldn't go through all these pushups for simple chrs */
|
|
|
|
assert(c > MAX_SIMPLE_CHR);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: we should not see requests to consider cclasses that are not
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
* treated as locale-specific by cclasscvec(), above.
|
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
|
|
|
*/
|
|
|
|
if (cm->classbits[CC_PRINT] && pg_wc_isprint(c))
|
|
|
|
colnum |= cm->classbits[CC_PRINT];
|
|
|
|
if (cm->classbits[CC_ALNUM] && pg_wc_isalnum(c))
|
|
|
|
colnum |= cm->classbits[CC_ALNUM];
|
|
|
|
if (cm->classbits[CC_ALPHA] && pg_wc_isalpha(c))
|
|
|
|
colnum |= cm->classbits[CC_ALPHA];
|
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
2021-02-25 19:00:40 +01:00
|
|
|
if (cm->classbits[CC_WORD] && pg_wc_isword(c))
|
|
|
|
colnum |= cm->classbits[CC_WORD];
|
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
|
|
|
assert(cm->classbits[CC_ASCII] == 0);
|
|
|
|
assert(cm->classbits[CC_BLANK] == 0);
|
|
|
|
assert(cm->classbits[CC_CNTRL] == 0);
|
|
|
|
if (cm->classbits[CC_DIGIT] && pg_wc_isdigit(c))
|
|
|
|
colnum |= cm->classbits[CC_DIGIT];
|
|
|
|
if (cm->classbits[CC_PUNCT] && pg_wc_ispunct(c))
|
|
|
|
colnum |= cm->classbits[CC_PUNCT];
|
|
|
|
assert(cm->classbits[CC_XDIGIT] == 0);
|
|
|
|
if (cm->classbits[CC_SPACE] && pg_wc_isspace(c))
|
|
|
|
colnum |= cm->classbits[CC_SPACE];
|
|
|
|
if (cm->classbits[CC_LOWER] && pg_wc_islower(c))
|
|
|
|
colnum |= cm->classbits[CC_LOWER];
|
|
|
|
if (cm->classbits[CC_UPPER] && pg_wc_isupper(c))
|
|
|
|
colnum |= cm->classbits[CC_UPPER];
|
|
|
|
if (cm->classbits[CC_GRAPH] && pg_wc_isgraph(c))
|
|
|
|
colnum |= cm->classbits[CC_GRAPH];
|
|
|
|
|
|
|
|
return colnum;
|
|
|
|
}
|
|
|
|
|
2003-02-05 18:41:33 +01:00
|
|
|
/*
|
|
|
|
* allcases - supply cvec for all case counterparts of a chr (including itself)
|
|
|
|
*
|
|
|
|
* This is a shortcut, preferably an efficient one, for simple characters;
|
|
|
|
* messy cases are done via range().
|
|
|
|
*/
|
|
|
|
static struct cvec *
|
2017-06-21 20:39:04 +02:00
|
|
|
allcases(struct vars *v, /* context */
|
2016-08-19 18:51:02 +02:00
|
|
|
chr c) /* character to get case equivs of */
|
2003-02-05 18:41:33 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
struct cvec *cv;
|
|
|
|
chr lc,
|
|
|
|
uc;
|
2003-02-05 18:41:33 +01:00
|
|
|
|
2016-08-19 18:51:02 +02:00
|
|
|
lc = pg_wc_tolower(c);
|
|
|
|
uc = pg_wc_toupper(c);
|
2003-02-05 18:41:33 +01:00
|
|
|
|
2008-02-14 18:33:37 +01:00
|
|
|
cv = getcvec(v, 2, 0);
|
2003-08-04 02:43:34 +02:00
|
|
|
addchr(cv, lc);
|
|
|
|
if (lc != uc)
|
|
|
|
addchr(cv, uc);
|
|
|
|
return cv;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* cmp - chr-substring compare
|
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Backrefs need this. It should preferably be efficient.
|
2003-02-05 18:41:33 +01:00
|
|
|
* Note that it does not need to report anything except equal/unequal.
|
|
|
|
* Note also that the length is exact, and the comparison should not
|
|
|
|
* stop at embedded NULs!
|
|
|
|
*/
|
2003-08-04 02:43:34 +02:00
|
|
|
static int /* 0 for equal, nonzero for unequal */
|
2003-08-08 23:42:59 +02:00
|
|
|
cmp(const chr *x, const chr *y, /* strings to compare */
|
2003-08-04 02:43:34 +02:00
|
|
|
size_t len) /* exact length of comparison */
|
2003-02-05 18:41:33 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
return memcmp(VS(x), VS(y), len * sizeof(chr));
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* casecmp - case-independent chr-substring compare
|
|
|
|
*
|
|
|
|
* REG_ICASE backrefs need this. It should preferably be efficient.
|
|
|
|
* Note that it does not need to report anything except equal/unequal.
|
|
|
|
* Note also that the length is exact, and the comparison should not
|
|
|
|
* stop at embedded NULs!
|
|
|
|
*/
|
2003-08-04 02:43:34 +02:00
|
|
|
static int /* 0 for equal, nonzero for unequal */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
casecmp(const chr *x, const chr *y, /* strings to compare */
|
2003-02-05 18:41:33 +01:00
|
|
|
size_t len) /* exact length of comparison */
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
for (; len > 0; len--, x++, y++)
|
|
|
|
{
|
2004-05-07 02:24:59 +02:00
|
|
|
if ((*x != *y) && (pg_wc_tolower(*x) != pg_wc_tolower(*y)))
|
2003-08-04 02:43:34 +02:00
|
|
|
return 1;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
return 0;
|
2003-02-05 18:41:33 +01:00
|
|
|
}
|