This is a critical bug fix for a data corruption bug. If you
authorAndrew Tridgell <tridge@samba.org>
Thu, 31 Jul 2003 04:01:32 +0000 (04:01 +0000)
committerAndrew Tridgell <tridge@samba.org>
Thu, 31 Jul 2003 04:01:32 +0000 (04:01 +0000)
commitddf3c6d5ccedcf3bcd7d1361d91d638471644495
tree51570baa1f0137d307020eb297e7cb8813de2d9a
parentba12e6bb5fcfbf4bdba8f2c38978d38e1f857286
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)
source3/include/byteorder.h