From bbad8f6d72f2be5bf3556c57e06d1ae604f1be36 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher Date: Thu, 28 Jun 2012 09:54:41 +0200 Subject: s3:brlock: s/int/uint64_t for fnum fsp->fnum and lock->fnum are uint64_t already and we should not truncate the value here. Currently this doesn't matter as we only use 16-bit. But as 'int' is int32_t and we later compare fnum with lock->fnum == fnum, the cast from int32_t to uint64_t goes via int64_t instead of uint32_t. This means even if fsp->fnum just uses 32-bit of the uint64_t we'll get the wrong result, as the implicit cast from a negative int32_t value to uint64_t adds 0xFFFFFFFF00000000. metze --- source3/locking/brlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'source3/locking/brlock.c') diff --git a/source3/locking/brlock.c b/source3/locking/brlock.c index c70edec893..efde59952e 100644 --- a/source3/locking/brlock.c +++ b/source3/locking/brlock.c @@ -1487,7 +1487,7 @@ void brl_close_fnum(struct messaging_context *msg_ctx, { files_struct *fsp = br_lck->fsp; uint32_t tid = fsp->conn->cnum; - int fnum = fsp->fnum; + uint64_t fnum = fsp->fnum; unsigned int i; struct lock_struct *locks = br_lck->lock_data; struct server_id pid = messaging_server_id(fsp->conn->sconn->msg_ctx); -- cgit