Re: [Bug-XBoard] We distribute wrongly compiled WinBoard binaries

[Tim Mann]

On Tue, 02 Feb 2010 23:21:14 +0100, "h.g. muller" <address@hidden> wrote:
> >The compiler warnings probably need to be fixed by using the correct
> >variable types.  I'm surprised they aren't bugs... however, I haven't
> >seen the actual warnings so I don't really know what the problem is
> >there.  
> 
> The warnings are these:
> 
> $ make -f makefile.gcc
>   ../backend.c
> ../backend.c: In function `HandleMachineMove':
> ../backend.c:7423: warning: unsigned int format, different type arg (arg 7)
> ../backend.c:7548: warning: unsigned int format, different type arg (arg 4)
> ../backend.c:7611: warning: unsigned int format, different type arg (arg 7)

The line numbers don't match with the version of backend.c that I have,
but I think the first one is trying to print the variable "u64 nodes"
using "u64Display" format.

I guess after your change you're compiling with u64 #defined to
unsigned long long and u64Display #defined to "%I64u"...?  Maybe gcc
doesn't understand that such values match the format and gives you a
warning, but it works anyway because gcc pushes 64 bits on the stack
and the Windows libc printf correctly consumes 64 bits.

Hmm, I'll bet gcc is doing its printf type checking expecting the glibc
implementation of printf.  Looking at the printf(3) man page on Linux,
the "I" flag character means something different there:

       glibc 2.2 adds one further flag character.

       I      For  decimal  integer  conversion  (i, d, u) the output uses the
              locale's alternative output digits, if any.  For example,  since
              glibc  2.2.3  this  will give Arabic-Indic digits in the Persian
              ("fa_IR") locale.

So to glibc, %I64u means "an unsigned int, printed in a minimum
64-character wide field, using the locale's alternative output digits,
if any [otherwise its normal output digits]".  Ugh!

-- 
Tim Mann  address@hidden  http://tim-mann.org/