aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces/libpq/fe-secure-gssapi.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-01-08 12:16:00 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-01-08 12:16:00 -0500
commitafcc8772edcec687d87b6f762ca6113229af7291 (patch)
tree8d2824f0e3f80518608ce94aaabd6570a6adf2fe /src/interfaces/libpq/fe-secure-gssapi.c
parent15b824da97afb45f47e51b6b5b7e5eca09e5d03d (diff)
downloadpostgresql-afcc8772edcec687d87b6f762ca6113229af7291.tar.gz
postgresql-afcc8772edcec687d87b6f762ca6113229af7291.zip
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
Diffstat (limited to 'src/interfaces/libpq/fe-secure-gssapi.c')
0 files changed, 0 insertions, 0 deletions