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- all the way.
Discussion: https://postgr.es/m/16814-
6c5e3edd2bdf0d50@postgresql.org
case CHR('*'):
if (LASTTYPE(EMPTY) || LASTTYPE('(') || LASTTYPE('^'))
RETV(PLAIN, c);
- RET('*');
+ RETV('*', 1);
break;
case CHR('['):
if (HAVE(6) && *(v->now + 0) == CHR('[') &&
-- expectError 7.15 - a*+ BADRPT
select * from test_regex('a*+', '', '-');
ERROR: invalid regular expression: quantifier operand invalid
+-- test for ancient brenext() bug; not currently in Tcl
+select * from test_regex('.*b', 'aaabbb', 'b');
+ test_regex
+------------
+ {0}
+ {aaabbb}
+(2 rows)
+
-- doing 8 "braces"
-- expectMatch 8.1 NQ "a{0,1}" "" ""
select * from test_regex('a{0,1}', '', 'NQ');
select * from test_regex('a+*', '', '-');
-- expectError 7.15 - a*+ BADRPT
select * from test_regex('a*+', '', '-');
+-- test for ancient brenext() bug; not currently in Tcl
+select * from test_regex('.*b', 'aaabbb', 'b');
-- doing 8 "braces"