On-line engine blitz tourney February

[Joost Buijs]

There are very weird constructions in the source, for instance things this:

if (onColor >= 0 && onPiece >= 0) // allow placement in holdings
gs->holding[onColor == BLACK][onPiece-1]++;

The index goes very likely out of bounds if onPiece == 0, to fix this I first have to find out what onPiece exactly does. And there are many things like this in the source.

I don't know if it's worthwhile to fix this mess.

oof, maybe onPiece was supposed to be > 0? this looks like some code for a variant, hard to say

in general - maybe worth giving it a shot with address/thread sanitizer enabled to see if it finds something,
unlike static analyzers they are reliable

I will try to fix everything that is obvious, and it's a good idea to run the address sanitizer on it. Debugging it is cumbersome because I have to run 'real' tournaments for it to succeed.

It could be that one of the participants sends malformed commands or data that breaks the parser(s) somewhere, fscanf and sscanf are used throughout, these are very unsafe functions, and I don't think 'safe' string-functions like sscanf_s are available for Linux compilers (at least not officially).

[flok]

and I don't think 'safe' string-functions like sscanf_s are available for Linux compilers (at least not officially).

of course they are
you could've googled that

[Joost Buijs]

and I don't think 'safe' string-functions like sscanf_s are available for Linux compilers (at least not officially).

of course they are
you could've googled that

I've googled a lot. It seems these functions are added to the C11 specification (Annex-K), but most compilers didn't implemented them.
Mayby there are 3th party libs, I don't know, It's usually not a good idea to use stuff that has not been tested thoroughly.

[hgm]

There are very weird constructions in the source, for instance things this:

if (onColor >= 0 && onPiece >= 0) // allow placement in holdings
gs->holding[onColor == BLACK][onPiece-1]++;

The index goes very likely out of bounds if onPiece == 0, to fix this I first have to find out what onPiece exactly does. And there are many things like this in the source.

I don't know if it's worthwhile to fix this mess.

This is in board.c, where start positions are set up according to instructions read from a file. This particular statement occurs in case the file specifies that the game in question uses 'holdings' for captured pieces that can be dropped as in Crazyhouse / Bughouse / Shogi. The onPiece-1 actually is onPiece-PAWN, where PAWN has the lowest code of any piece, and onPiece is set to the piece code when the board parser reads the corresponding piece ID ('P' for a Pawn) in the startposition file. onPiece is initialized to -1 at its declaration. The value of onPiece is set in the switch statement just before these lines, which does not contain a case that would set it to 0.

So this line cannot cause any problems. Certainly not in normal Chess, which does not start with piece 'in hand'.