diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-01-08 12:16:00 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-01-08 12:16:00 -0500 |
| commit | 085a1cfb3d5fd767eb66e7c5bd7ed7818a7d717f (patch) | |
| tree | 415a600297208187497710ded3c31720ded1589b /src/backend/regex | |
| parent | 388ec04f14366d5df0c9b7958c5d9c09d4327f3a (diff) | |
Fix ancient bug in parsing of BRE-mode regular expressions.
brenext(), when parsing a '*' quantifier, forgot to return any "value"
for the token; per the equivalent case in next(), it should return
value 1 to indicate that greedy rather than non-greedy behavior is
wanted. The result is that the compiled regexp could behave like 'x*?'
rather than the intended 'x*', if we were unlucky enough to have
a zero in v->nextvalue at this point. That seems to happen with some
reliability if we have '.*' at the beginning of a BRE-mode regexp,
although that depends on the initial contents of a stack-allocated
struct, so it's not guaranteed to fail.
Found by Alexander Lakhin using valgrind testing. This bug seems
to be aboriginal in Spencer's code, so back-patch all the way.
Discussion: https://postgr.es/m/16814-6c5e3edd2bdf0d50@postgresql.org
Diffstat (limited to 'src/backend/regex')
| -rw-r--r-- | src/backend/regex/regc_lex.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/regex/regc_lex.c b/src/backend/regex/regc_lex.c index f62ec7dc810..f9118e8e42a 100644 --- a/src/backend/regex/regc_lex.c +++ b/src/backend/regex/regc_lex.c @@ -995,7 +995,7 @@ brenext(struct vars * v, case CHR('*'): if (LASTTYPE(EMPTY) || LASTTYPE('(') || LASTTYPE('^')) RETV(PLAIN, c); - RET('*'); + RETV('*', 1); break; case CHR('['): if (HAVE(6) && *(v->now + 0) == CHR('[') && |