Fix RESTORE ttl handling in 32 bit archs.

long was used instead of long long in order to handle a 64 bit
resolution millisecond timestamp.

This fixes issue #1483.
This commit is contained in:
antirez 2014-01-09 11:09:23 +01:00
parent e1ab2991c3
commit 58c8a071a5
1 changed files with 4 additions and 3 deletions

View File

@ -2959,7 +2959,7 @@ void dumpCommand(redisClient *c) {
/* RESTORE key ttl serialized-value [REPLACE] */
void restoreCommand(redisClient *c) {
long ttl;
long long ttl;
rio payload;
int j, type, replace = 0;
robj *obj;
@ -2981,7 +2981,7 @@ void restoreCommand(redisClient *c) {
}
/* Check if the TTL value makes sense */
if (getLongFromObjectOrReply(c,c->argv[2],&ttl,NULL) != REDIS_OK) {
if (getLongLongFromObjectOrReply(c,c->argv[2],&ttl,NULL) != REDIS_OK) {
return;
} else if (ttl < 0) {
addReplyError(c,"Invalid TTL value, must be >= 0");
@ -2989,7 +2989,8 @@ void restoreCommand(redisClient *c) {
}
/* Verify RDB version and data checksum. */
if (verifyDumpPayload(c->argv[3]->ptr,sdslen(c->argv[3]->ptr)) == REDIS_ERR) {
if (verifyDumpPayload(c->argv[3]->ptr,sdslen(c->argv[3]->ptr)) == REDIS_ERR)
{
addReplyError(c,"DUMP payload version or checksum are wrong");
return;
}