postgres.git / summary / log / commit / refs

commit    085a1cfb3d5fd767eb66e7c5bd7ed7818a7d717f
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Fri Jan 08 17:16:00 2021 +0000

    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


 src/backend/regex/regc_lex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/regex/regc_lex.c b/src/backend/regex/regc_lex.c
index f62ec7dc810..f9118e8e42a 100644
--- a/src/backend/regex/regc_lex.c
+++ b/src/backend/regex/regc_lex.c
@@ -995,7 +995,7 @@ brenext(struct vars * v,
 		case CHR('*'):
 			if (LASTTYPE(EMPTY) || LASTTYPE('(') || LASTTYPE('^'))
 				RETV(PLAIN, c);
-			RET('*');
+			RETV('*', 1);
 			break;
 		case CHR('['):
 			if (HAVE(6) && *(v->now + 0) == CHR('[') &&


[parent: 388ec04f1436]