Movatterモバイル変換


[0]ホーム

URL:


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

Sign up
Appearance settings

Commit49c928c

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 returnvalue 1 to indicate that greedy rather than non-greedy behavior iswanted. The result is that the compiled regexp could behave like 'x*?'rather than the intended 'x*', if we were unlucky enough to havea zero in v->nextvalue at this point. That seems to happen with somereliability if we have '.*' at the beginning of a BRE-mode regexp,although that depends on the initial contents of a stack-allocatedstruct, so it's not guaranteed to fail.Found by Alexander Lakhin using valgrind testing. This bug seemsto be aboriginal in Spencer's code, so back-patch all the way.Discussion:https://postgr.es/m/16814-6c5e3edd2bdf0d50@postgresql.org
1 parent5ba0469 commit49c928c

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
caseCHR('*'):
995995
if (LASTTYPE(EMPTY)||LASTTYPE('(')||LASTTYPE('^'))
996996
RETV(PLAIN,c);
997-
RET('*');
997+
RETV('*',1);
998998
break;
999999
caseCHR('['):
10001000
if (HAVE(6)&&*(v->now+0)==CHR('[')&&

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp