Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit 085a1cf

Browse filesBrowse files
tglsfdctglsfdc
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
Copy full SHA for 085a1cf

File tree

Expand file treeCollapse file tree

1 file changed

+1
-1
lines changed
Filter options
Expand file treeCollapse file tree

1 file changed

+1
-1
lines changed

‎src/backend/regex/regc_lex.c

Copy file name to clipboardExpand all lines: src/backend/regex/regc_lex.c
+1-1Lines changed: 1 addition & 1 deletion
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 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.