Author: Sune Fischer
Date: 01:14:00 07/04/02
Go up one level in this thread
On July 03, 2002 at 21:21:05, Robert Hyatt wrote: >On July 03, 2002 at 17:57:37, Sune Fischer wrote: > >>On July 03, 2002 at 17:00:49, Robert Hyatt wrote: >> >>>On July 03, 2002 at 16:09:37, Sune Fischer wrote: >>> >>>>Hi quick question. >>>> >>>>// this one is "faulty": >>>>#define RANK64(r) (0x00000000000000FF<<(r<<3)) // r is 0-7 >>>> >>> >>>That long number is _not_ a 64 bit value. If you cast the hex constant >>>to 64 bits, the shift amount doesn't need to be cast (and it might well be >>>more efficient that way as well). >> >>Then it has to be because of the leading zeros, because usually it _is_ a 64 bit >>number. The same trick on the file worked great, but that number is >>0x0101010101010101, which is then correctly read as a 64 bit type. >> >>-S. > > >That is the problem. ie 0x000000000000000000000000000000000000001 is still a >small number. Leading zeros get ignored... Yes, but IMO the compiler should give a warning here, there is no long long long long type :) I'm curious, is 0xff then used as an 4 byte integer and not as a char? So I might as well use 0xf instead of 0x0f or 0x0000000f, its all the same to the compiler? -S.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.