Author: Omid David Tabibi
Date: 05:18:25 02/08/04
Go up one level in this thread
On February 08, 2004 at 05:05:22, David Dory wrote:
>My run time errors, where simple variable assignments would work in the first
>for loop, and blatantly fail in the next, have been found and bug sprayed.
>
>It seems, perhaps, a certain coder didn't notice a global variable had (cough,
>cough), also been inserted as a parameter to the misbehaving function.
>
>The first for loop, incremented the loop counter, and worked fine:
>for(i = 1; i <= movenum; i++) {
> //first time thru, i == 1, here
> some_array[i] accessed and tested here
>}
>
>The second for loop, the loop counter was totally "hidden", and couldn't be
>assigned a simple value, even.
>
>for(i = 1; i <= movenum; i++) {
> //first time thru, i == 8596128, (total crap value)
> some_array[i] access causes fatal exception, naturally
>}
>
>So Bill and Co. can rest easy, I guess.
>
>For me, this was just a run time error, with no warnings from the compiler.
>
Under MSVC, test the following:
unsigned __int64 a = (1 << 50);
printf("%I64u\n", a);
What will the result be?... 0 ! No errors, no warnings.
After debugging for several hours I finally found the problem and fixed it
using:
unsigned __int64 a = (1ui64 << 50);
Yes, 1 should be written as 1ui64, or another solution:
unsigned __int64 a = (((unsigned __int64) 1) << 50);
Casting 1 to 64 bit.
This is just a stupidity of MSVC. I was told that the Intel compiler gives an
appropriate warning for the statement (1 << 50), and handles it correctly as 64
bit.
>David
This page took 0.01 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.