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)

diff --git a/source3/include/byteorder.h b/source3/include/byteorder.h
index c262dd2d3374ea3da74b68acc9740ecc10389019..63696fa85800df0981317d8082103ac53ecd231b 100644 (file)
--- a/source3/include/byteorder.h
+++ b/source3/include/byteorder.h
@@ -105,8 +105,8 @@ it also defines lots of intermediate macros, just ignore those :-)
 #define CAREFUL_ALIGNMENT 1
 #endif
 
-#define CVAL(buf,pos) (((const unsigned char *)(buf))[pos])
-#define CVAL_NC(buf,pos) (((unsigned char *)(buf))[pos]) /* Non-const version of CVAL */
+#define CVAL(buf,pos) ((unsigned)(((const unsigned char *)(buf))[pos]))
+#define CVAL_NC(buf,pos) ((unsigned)(((unsigned char *)(buf))[pos])) /* Non-const version of CVAL */
 #define PVAL(buf,pos) (CVAL(buf,pos))
 #define SCVAL(buf,pos,val) (CVAL_NC(buf,pos) = (val))