Polyglot 1.5w bugfix

[H.G.Muller]

The polyglot.exe included in the WinBoard Gold Pack turned out to contain a bug (PV was not printed). For those who already downloaded the Gold Pack, you can replace the polyglot.exe there (in the folder Polyglot15w) by the bug-fixed version here.

[Jim Ablett]

The polyglot.exe included in the WinBoard Gold Pack turned out to contain a bug (PV was not printed). For those who already downloaded the Gold Pack, you can replace the polyglot.exe there (in the folder Polyglot15w) by the bug-fixed version here.

(PV was not printed)

Seems like it's contagious

Jim.

[H.G.Muller]

The reason in this case was entirely different, though: the compiler I used (Cygwin) did not understand the %lld format for printing the long long int node count. As a consequence it used the high-order word of this count as what should have been a pointer to the PV text (which follows the node count in WB thinking output). Normally you would seg-fault on such a bug, but in this case it led to printing of the word 'nodes' in stead of the PV!

[Sven Schüle]

Just curious: how did you fix the %lld problem? With %Ld, with %I64d (Microsoft - that would surprise me), or anything different?

And which compiler + version exactly is it you use under CygWin?

Sven

[H.G.Muller]

Michel fixed it for me, by making the format dependent on a compiler switch. I think for Cygwin and Mingw it uses the %I64d.

I might have used an obsolete g++ on my desktop when making the original compile under Cygwin. It was the first time in my life I compiled a C++ program, I was surprised to learn thatI had the compiler installed.

But when I made a small test on my laptop printing a long long and a counting int behind it with the format "%lld %d" there was no problem at all. So perhaps the fix in the source would not have been needed. (It would have been needed for MVC, though.)

I have no idea which versions exactly I have installed, or even how I could see that.

[Sven Schüle]

I have no idea which versions exactly I have installed, or even how I could see that.

I would try
% bash --version
% g++ --version
% ls -l /usr/bin/cygwin1.dll
for example.

As to the %lld vs. %I64d issue, I am quite surprised that your g++ wanted the latter in case of Polyglot. But after searching in CCC I found that this has been reported already a few days ago here:
http://www.talkchess.com/forum/viewtopic.php?t=22008&start=53

Sven

[H.G.Muller]

Code: Select all

Administrator@fom-rhka8j2a5wy ~
$ bash --version
GNU bash, version 3.2.25(16)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.

Administrator@fom-rhka8j2a5wy ~
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Administrator@fom-rhka8j2a5wy ~
$ ls -l /usr/bin/cygwin1.dll
-rwxrwxrwx 1 Administrator Users 1873811 Jan 31  2007 /usr/bin/cygwin1.dll

Administrator@fom-rhka8j2a5wy ~
$


[Michel]

Some points

(1) The "Cygwin compiler" when invoked with -mno-cygwin is really just a version of Mingw.

(2) This is not Mingw's fault. Mingw calls the native win32 printf which does not understand %lld (even though this is in the more recent c standards).

Rather than complicated compiler checking it would probably be better to use #ifdef _WIN3. Compilers (like Mingw32) that link with the native win32 libraries will likely set _WIN32.

(3) It is however still a unclear to me how Fonzy Bleumers could produce a working version of PG with the Microsoft compiler....Maybe the Microsoft compiler actually patches the format string before passing it on to the native printf?

[Teemu Pudas]

(3): It's been fixed in MSVC2008.

[Michel]

What do you mean by fixed?

Does MSVC2008 parse the format string before passing it on to the native printf (which Mingw also uses and apparently does still not support %lld)?

Parsing the format string is fragile since the format string might be generated at runtime.

Or does the MSV2008 runtime include a new printf which overrides somehow the old printf?

[Michel]

It seems that the MSVC2008 runtime does indeed support %lld.

http://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx

I am still wondering what this means. It could mean that the MSVC2008 runtime
has a replacement for printf. But then it would have to be statically linked, for it
to be available on computers that do not have this runtime installed.

[F. Bluemers]

It seems that the MSVC2008 runtime does indeed support %lld.

http://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx

I am still wondering what this means. It could mean that the MSVC2008 runtime
has a replacement for printf. But then it would have to be statically linked, for it
to be available on computers that do not have this runtime installed.

Hi Michel,
Eric Mullins has fixed the issue for older MS compilers,
http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=197575&t=22008
The updated sources are on my site.
Best
Fonzy

[Michel]

Hi Michel,
Eric Mullins has fixed the issue for older MS compilers,
http://www.talkchess.com/forum/viewtopi ... 75&t=22008
The updated sources are on my site.
Best

Well I have fixed it as well I think. I have conditionally replaced %lld by %I64d.

But this is not a compiler issue but rather a library issue (since printf is a function
and not a C statement).

So I was wondering it the binary you distributed had the C library statically linked?
Otherwise I could not see how a binary produced by MSVC2008 could work
correctly on systems which do not have the MSVC2008 C library installed.


Regards,
Michel

[Harald Lüßen]

In the compiler dependent header where you do things like

#ifdef _WIN32
typedef unsigned char byte;
typedef __int64 int64;
typedef unsigned __int64 uint64;
typedef __int32 int32;
typedef unsigned __int32 uint32;
typedef __int16 int16;
typedef unsigned __int16 uint16;
#else
...
#endif

I do also this

#ifdef _WIN32
#define C64(c) c##ui64
#define U64_F "I64u"
#define X64_F "016I64x"
#define X64_S "I64x"
#else
...
#endif

And I use it like this:

uint64 val = C64(0x8080808080808080);
printf( "some number %"U64_F" in a portable format\n", val );
printf( "and here in hex %"X64_F"\n", val );
scanf( "%"X64_S), &val );

Harald

[Teemu Pudas]

So I was wondering it the binary you distributed had the C library statically linked? Otherwise I could not see how a binary produced by MSVC2008 could work correctly on systems which do not have the MSVC2008 C library installed.

It wouldn't even run.

[Eric Mullins]

Michel fixed it for me, by making the format dependent on a compiler switch. I think for Cygwin and Mingw it uses the %I64d.

I might have used an obsolete g++ on my desktop when making the original compile under Cygwin. It was the first time in my life I compiled a C++ program, I was surprised to learn thatI had the compiler installed.

But when I made a small test on my laptop printing a long long and a counting int behind it with the format "%lld %d" there was no problem at all. So perhaps the fix in the source would not have been needed. (It would have been needed for MVC, though.)

I have no idea which versions exactly I have installed, or even how I could see that.

For polyglot, the problem is twofold:

First, there were hardcoded "%lld" strings in the source instead of the proper S64_FORMAT defined in util.h

Second, S64_FORMAT has to be defined properly there as well. For polyglot, this meant adding _WIN32 in the check instead of just _MSC_VER. I'm pretty sure you need "%I64d" for anything linking with MSVCRT. That includes cygwin if you use the -mno_cygwin or whatever that switch is. Without that switch, you want "%lld" and that's what you'll get with cygwin because _WIN32 won't be defined.

Most toga sources I have found suffer from the latter problem. They properly use S64_FORMAT, but don't set it properly. That is why people have difficulty getting good toga builds using dev-cpp, but not with MS compilers.

Later versions of Visual Studio do not suffer from this issue, and work properly regardless if it is "%lld" or "%I64d", which is why some people don't see the problem. I presume because Visual Studio 2005 and later don't link with MSVCRT. The problem occurs in the vsprintf() and vprintf() routines in the MSVCRT runtime, I'm pretty sure.

[H.G.Muller]

How would MSVCRT get installed on my system? Does that come automatically with Win2k, or with Cygwin?

[Michel]

How would MSVCRT get installed on my system? Does that come automatically with Win2k, or with Cygwin?

This is the MSVC runtime. I think some version comes default with Windows but
you can install more recent versions (or they come with more recent versions of MSVC).
It is a big mess.