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

Commit0c23f30

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 parent155bfbb commit0c23f30

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
@@ -968,7 +968,7 @@ brenext(struct vars * v,
968968
caseCHR('*'):
969969
if (LASTTYPE(EMPTY)||LASTTYPE('(')||LASTTYPE('^'))
970970
RETV(PLAIN,c);
971-
RET('*');
971+
RETV('*',1);
972972
break;
973973
caseCHR('['):
974974
if (HAVE(6)&&*(v->now+0)==CHR('[')&&

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp