Skip to content

Commit 49c928c

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 5ba0469 commit 49c928c

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/backend/regex/regc_lex.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -994,7 +994,7 @@ brenext(struct vars *v,
994994
case CHR('*'):
995995
if (LASTTYPE(EMPTY) || LASTTYPE('(') || LASTTYPE('^'))
996996
RETV(PLAIN, c);
997-
RET('*');
997+
RETV('*', 1);
998998
break;
999999
case CHR('['):
10001000
if (HAVE(6) && *(v->now + 0) == CHR('[') &&

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy