Skip to content

Commit 085a1cf

Browse files
committed
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
1 parent 388ec04 commit 085a1cf

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/backend/regex/regc_lex.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -995,7 +995,7 @@ brenext(struct vars * v,
995995
case CHR('*'):
996996
if (LASTTYPE(EMPTY) || LASTTYPE('(') || LASTTYPE('^'))
997997
RETV(PLAIN, c);
998-
RET('*');
998+
RETV('*', 1);
999999
break;
10001000
case CHR('['):
10011001
if (HAVE(6) && *(v->now + 0) == CHR('[') &&

0 commit comments

Comments
 (0)