1
0
mirror of https://github.com/postgres/postgres.git synced 2025-08-22 21:53:06 +03:00

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
This commit is contained in:
Tom Lane
2019-10-04 10:34:21 -04:00
parent 54d641da06
commit 8b77f783b7
3 changed files with 76 additions and 2 deletions

View File

@@ -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);
}