[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnugo-devel] bug in hashdata_init for 64 bit longs
From: |
Teun Burgers |
Subject: |
[gnugo-devel] bug in hashdata_init for 64 bit longs |
Date: |
Tue, 03 Feb 2004 19:05:58 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
On Tru64 compiling 3.5.4 results in the following warning when
compile cache.c:
cc -DHAVE_CONFIG_H -I. -I. -I.. -I../patterns -I../patterns -I../sgf
-I../utils -c `test -f cache.c || echo './'`cache.c
cc: Warning: cache.c, line 88: In this statement, the shift count "32"
is negative or is greater than or equal to the promoted size of the
operand "(gg_urand(...))". (shiftcount)
hashdata_init(array[j], gg_urand(), gg_urand());
------^
The problem is that uint1 in the following snippet is shifted to zero.
resulting in 64 bit hash values with the first 32 bits being zero.
The problem is fixed I think by this patch that promotes uint1 (32 bit)
to a Hashvalue (64 bit on Tru64) before shifting.
Teun
--- gnugo-3.5.4.orig/engine/hash.h 2004-01-24 04:26:22.000000000 +0100
+++ gnugo-3.5.4/engine/hash.h 2004-02-03 11:50:00.000000000 +0100
@@ -117,7 +117,7 @@
} while (0)
#define hashdata_init(hd, uint1, uint2) \
do { \
- (hd).hashval[0] = ((uint1) << 32 | (uint2)); \
+ (hd).hashval[0] = (((Hashvalue) uint1) << 32 | (uint2)); \
} while (0)
#define hashdata_is_equal(hd1, hd2) \
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gnugo-devel] bug in hashdata_init for 64 bit longs,
Teun Burgers <=