diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-10-04 10:34:21 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-10-04 10:34:21 -0400 |
| commit | 8b77f783b7584e8cbcf0aa42c7f176f7f23937ae (patch) | |
| tree | 061782d981e65447e9a137409b12e07a844e36dd /src/backend/utils/adt/varbit.c | |
| parent | 54d641da0640bf2f1fb2adb346c76638911b5df3 (diff) | |
| download | postgresql-8b77f783b7584e8cbcf0aa42c7f176f7f23937ae.tar.gz postgresql-8b77f783b7584e8cbcf0aa42c7f176f7f23937ae.zip | |
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
Diffstat (limited to 'src/backend/utils/adt/varbit.c')
| -rw-r--r-- | src/backend/utils/adt/varbit.c | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/src/backend/utils/adt/varbit.c b/src/backend/utils/adt/varbit.c index e6261fbb1a8..8a23194cf1d 100644 --- a/src/backend/utils/adt/varbit.c +++ b/src/backend/utils/adt/varbit.c @@ -1473,6 +1473,7 @@ bitshiftright(PG_FUNCTION_ARGS) /* Special case: we can do a memcpy */ len = VARBITBYTES(arg) - byte_shift; memcpy(r, p, len); + r += len; } else { @@ -1484,10 +1485,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); } |