Troubles with the stdin in own Windows compiles

[OliverBr]

Maybe someone knows of this issue:

When you open the Windows executable on CMD and then enter “uci” (3-character), the answer won’t show until the next command.
"uci " with space works fine, also "go", "stop", "ponder", "quit" as they have all "even" chars.
This issue has been reported/verified by others on their Windows PC.

I don’t think the problem lies in the code, because the linux/macosx executables work fine.
My own Windows compilations show this strange behaviour.
The problem does not appear with Jim Ablett's Windows compiles.

Code: Select all

	char line[8192];
	while(fgets(line, sizeof(line), stdin)) {

[Roland Chastain]

Weird. I would try this:

Code: Select all

printf("uciok\n");
fflush(stdout); // <---

I will test by myself this afternoon.

P.-S. I have just seen this:

Code: Select all

setbuf(stdout, NULL);

So it probably won't be useful to call fflush.

"uci " with space works fine

Weird.

[Jim Ablett]

I cross-compiled on Linux a Windows executable and it works correctly with no bug.

Code: Select all

CC=clang
CFLAGS=-O3 -Wall -Wextra -mavx2 -mllvm -align-all-nofallthru-blocks=6 -DNDEBUG --target=x86_64-windows-gnu -static
olithink: olithink.c

How are you cross-compiling. On a Mac ?

You could try cleaning up the input. Replace beginning of uci_loop().

Code: Select all

void uci_loop(int d) {
  while (fgets(line, sizeof(line), stdin)) {
    // Remove the newline and carriage return characters
    char *p = strchr(line, '\n');
    if (p) *p = '\0';
    p = strchr(line, '\r');
    if (p) *p = '\0';
    
    // Now perform the comparisons on the cleaned string
    if (strncmp(line, "ucinewgame", 10) == 0) {

Jim.

[benvining]

I believe it is the flushing issue, I experienced this too. In my C++ code I call

Code: Select all

std::cout.flush();

after printing the bestmove. Although now this is making me wonder if I might need to flush in other places too...

[Roland Chastain]

I compiled under Windows (with LLVM-MinGW). I could not reproduce the bug.

Maybe you could try to add this, so that you can see what happens?

Code: Select all

void uci_loop() {
  unsigned long i;
  char hex[256];
  char temp[5];
  while (fgets(line, sizeof(line), stdin)) {
    memset(&hex[0], 0, sizeof(hex));
    for ( i = 0; i < strlen(line); i++ )
    {
      memset(&temp[0], 0, sizeof(temp));
      sprintf(temp, "%0.2X", line[i]);
      strcat(hex, temp);
    }
    printf( "DEBUG line = [0x%s]\n", hex);

[OliverBr]

I cross-compiled on Linux a Windows executable and it works correctly with no bug.

Yes, I see and I am grateful for that.

Code: Select all

CC=clang
CFLAGS=-O3 -Wall -Wextra -mavx2 -mllvm -align-all-nofallthru-blocks=6 -DNDEBUG --target=x86_64-windows-gnu -static
olithink: olithink.c

How are you cross-compiling. On a Mac ?

I am not crosscompiling. I am using a Visual Studio C++ native compiler on a Windows 11 VDI Virtual Machine using this command:

Code: Select all

cl /O2 olithink.c

As I said before, former compilations by me of OlIThink have the same issue, but in xboard protocol it doesn't matter, because there is no vital command with odd number of characters, like "uci" in UCI protocol.

You could try cleaning up the input. Replace beginning of uci_loop().

Thank you to all who answered, I hope I will have to time to try the ideas soon.

[syzygy]

Change

Code: Select all

	setbuf(stdout, NULL);
	setbuf(stdin, NULL);

to

Code: Select all

	setlinebuf(stdout);
	setlinebuf(stdin);

?