From 6c3b6406db3b132b84d7be6fe838da9d46cd02f8 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 4 Oct 2019 10:34:21 -0400 Subject: Fix bitshiftright()'s zero-padding some more. Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of leaving one-bits in the pad space that should be all zeroes, because in a moment of sheer brain fade I'd concluded that only the code path used for not-a-multiple-of-8 shift distances needed to be fixed. Of course, a multiple-of-8 shift distance can also cause the problem, so we need to forcibly zero the extra bits in both cases. Per bug #16037 from Alexander Lakhin. As before, back-patch to all supported branches. Discussion: https://postgr.es/m/16037-1d1ebca564db54f4@postgresql.org --- src/backend/utils/adt/varbit.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'src/backend') diff --git a/src/backend/utils/adt/varbit.c b/src/backend/utils/adt/varbit.c index c36d8ded40a..cf1c9cd9926 100644 --- a/src/backend/utils/adt/varbit.c +++ b/src/backend/utils/adt/varbit.c @@ -1483,6 +1483,7 @@ bitshiftright(PG_FUNCTION_ARGS) /* Special case: we can do a memcpy */ len = VARBITBYTES(arg) - byte_shift; memcpy(r, p, len); + r += len; } else { @@ -1494,10 +1495,11 @@ bitshiftright(PG_FUNCTION_ARGS) if ((++r) < VARBITEND(result)) *r = (*p << (BITS_PER_BYTE - ishift)) & BITMASK; } - /* We may have shifted 1's into the pad bits, so fix that */ - VARBIT_PAD_LAST(result, r); } + /* We may have shifted 1's into the pad bits, so fix that */ + VARBIT_PAD_LAST(result, r); + PG_RETURN_VARBIT_P(result); } -- cgit v1.2.3