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

diff --git a/source3/locking/brlock.c b/source3/locking/brlock.c
index c70edec8930d295465668b6cb67243287e1bdfaa..efde59952eaaa377629f724086c54457bb163ac6 100644 (file)
--- 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);