| commit | bbad8f6d72f2be5bf3556c57e06d1ae604f1be36 | |
| author | Stefan Metzmacher <metze@samba.org> | |
| Thu, 28 Jun 2012 07:54:41 +0000 (28 09:54 +0200) | ||
| committer | Stefan Metzmacher <metze@samba.org> | |
| Thu, 28 Jun 2012 08:08:03 +0000 (28 10:08 +0200) | ||
| tree | b68b4aa05079c5a0295bdfbfee57e09ad1200a14 | treesnapshot (tar.gz zip) |
| parent | c5f1ab9a886104780ee65e43a5f36a3259df60f3 | commitdiff |
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
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 | diffblobblamehistory |