summaryrefslogtreecommitdiff
path: root/source3/passdb/pdb_ldap.c
diff options
context:
space:
mode:
authorAndrew Tridgell <tridge@samba.org>2003-07-31 04:01:32 +0000
committerAndrew Tridgell <tridge@samba.org>2003-07-31 04:01:32 +0000
commitddf3c6d5ccedcf3bcd7d1361d91d638471644495 (patch)
tree51570baa1f0137d307020eb297e7cb8813de2d9a /source3/passdb/pdb_ldap.c
parentba12e6bb5fcfbf4bdba8f2c38978d38e1f857286 (diff)
downloadsamba-ddf3c6d5ccedcf3bcd7d1361d91d638471644495.tar.gz
samba-ddf3c6d5ccedcf3bcd7d1361d91d638471644495.tar.bz2
samba-ddf3c6d5ccedcf3bcd7d1361d91d638471644495.zip
This is a critical bug fix for a data corruption bug. If you
maintain another tree then please apply! On non-X86 machines out byte-order macros fails for one particular value. If you asked for IVAL() of 0xFFFFFFFF and assigned it to a 64 bit quantity then you got a 63 bit number 0x7FFFFFFFFFFFFFFF rather than the expected 0xFFFFFFFF. This is due to some rather bizarre and obscure sign extension rules to do with unsigned chars and arithmetic operators (basically if you | together two unsigned chars you get a signed result!) This affected a byte range lock using the large lockingX format and a lock of offset 0 and length 0xFFFFFFFF. Microsoft Excel does one of these locks when opening a .csv file. If the platform you run on does not then handle locks of length 0x7FFFFFFFFFFFFFFF then the posix lock fails and the client is given a lockingX failure. This causes the .csv file to be trunated!! (This used to be commit 886661c3777dbfd4fa431746c8a5f48674a12b8e)
Diffstat (limited to 'source3/passdb/pdb_ldap.c')
0 files changed, 0 insertions, 0 deletions