BITOP bug when called against non existing keys fixed.

In the issue #529 an user reported a bug that can be triggered with the
following code:

flushdb
set a
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
bitop or x a b

The bug was introduced with the speed optimization in commit 8bbc076
that specializes every BITOP operation loop up to the minimum length of
the input strings.

However the computation of the minimum length contained an error when a
non existing key was present in the input, after a key that was non zero
length.

This commit fixes the bug and adds a regression test for it.
This commit is contained in:
antirez 2012-05-31 21:45:39 +02:00
parent bc70b8e5f4
commit 1419406e8d
2 changed files with 7 additions and 0 deletions

View File

@ -197,6 +197,7 @@ void bitopCommand(redisClient *c) {
objects[j] = NULL; objects[j] = NULL;
src[j] = NULL; src[j] = NULL;
len[j] = 0; len[j] = 0;
minlen = 0;
continue; continue;
} }
/* Return an error if one of the keys is not a string. */ /* Return an error if one of the keys is not a string. */

View File

@ -160,4 +160,10 @@ start_server {tags {"bitops"}} {
catch {r bitop xor dest a b c d} e catch {r bitop xor dest a b c d} e
set e set e
} {*ERR*} } {*ERR*}
test {BITOP with empty string after non empty string (issue #529)} {
r flushdb
r set a "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
r bitop or x a b
} {32}
} }