I decided to ask Leo to remove movei from his site

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 28 June 2004 21:42:56:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.
Uri

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 28 June 2004 21:51:19:
Als Antwort auf:/In reply to: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 28 June 2004 21:42:56:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.

If you give me the source for your fen parser, I will fix it for you.



my ftp site {remove http:// unless you like error messages}

[Matthias Gemuh]

Geschrieben von:/Posted by: Matthias Gemuh at 28 June 2004 22:27:18:
Als Antwort auf:/In reply to: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 28 June 2004 21:42:56:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.
Uri

Hi Uri,
this sounds like an overreaction to me. My BigLion has obvious nuisances,
for example:
1) log files cannot be switched off.
2) resign, but no resign offer.
3) Zero hash size is changed to 1 MB Hash.
4) wrong FEN can lead to crash.
5) 1000 moves causes premature exit.
6) fixed time per move not supported, or buggy.
7) fixed depth search not implemented.
8) ... etc.
However, if someone tells me to stop offering it for download,
I will use words against him which will force any moderator to step in quickly.
Ignore Dann and leave Movei on Leo's homepage, for the sake of thousands of
Movei fans worldwide.
/Matthias.



BigLion + Taktix

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 28 June 2004 22:32:41:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dann Corbit at 28 June 2004 21:51:19:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.

If you give me the source for your fen parser, I will fix it for you.

Thanks
It is bad programming and I use a lot of global varaibles in this function but I will post it here
My function is bigger but I decided to delete the last lines because they are not connected with the setup and they are only some initialization of global bitboards(I can change my program to call 2 functions instead of calling one function of setup and get rid of the last lines).
I can also change it not to include the first lines and have a special function that is going to call them(I think that I need to call them only at the start of the game and not in every setup but I am not sure now).
I think that the simplest way to solve the enpassant problem is to setup the position one ply before the position that is in the board and ask the program to make the 2 pawn move after it.
another problem is to detect cases when the king is threated from 3 directions
or that the side to move can capture the king or that both kings are under attack or that the king is attacked from 2 bishop directions.

void setup(char position[256])
{
int i=0;
int square=56;
int last=63;
char piece;
buildbasicarrays();
pseudostart();
while (position[i]!=' ')
{
if (position[i]'Z')
{
info[square]=DARKA;
piece=position[i];
}
else
{
info[square]=LIGHTA;
piece=(char)(position[i]+'a'-'A');
}
switch (piece)
{
case 'p':
info[square]+=PAWN;
pawnBB[color(square)]|=setmask[square];
pawn_files|=(1

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 28 June 2004 22:53:02:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Matthias Gemuh at 28 June 2004 22:27:18:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.
Uri

Hi Uri,
this sounds like an overreaction to me. My BigLion has obvious nuisances,
for example:
1) log files cannot be switched off.
2) resign, but no resign offer.
3) Zero hash size is changed to 1 MB Hash.
4) wrong FEN can lead to crash.
5) 1000 moves causes premature exit.
6) fixed time per move not supported, or buggy.
7) fixed depth search not implemented.
8) ... etc.
However, if someone tells me to stop offering it for download,
I will use words against him which will force any moderator to step in quickly.
Ignore Dann and leave Movei on Leo's homepage, for the sake of thousands of
Movei fans worldwide.
/Matthias.

Based on Dann corbit there is no problem with premature exit that is not a crash.
There is no problem with not supporting all the options if the program does not crash.
Again no problem with it.
Thanks for the support to include movei in Leo's page and I will wait to see what other say about it.
For now my decision is to remove it from Leo's page
I may consider if to change my mind later.
Uri

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 28 June 2004 23:25:35:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 28 June 2004 22:32:41:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]



my ftp site {remove http:// unless you like error messages}

[Volker Boehm]

Geschrieben von:/Posted by: Volker Boehm at 28 June 2004 23:27:52:
Als Antwort auf:/In reply to: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 28 June 2004 21:42:56:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.
Uri

How can anybody profit from this bugs as a chess program does not listen to any ports?
Greetings Mangar

[Anastasios Milikas]

Geschrieben von:/Posted by: Anastasios Milikas at 28. June 2004 23:42:
Als Antwort auf:/In reply to: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 28 June 2004 21:42:56:

So we have to remove the 99.9% of all Windows programs because they all crash occasionaly!

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 28 June 2004 23:48:23:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dann Corbit at 28 June 2004 23:25:35:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

basic definition in def.h:
typedef unsigned __int64 BitBoard;
Here are the definitions of the global arrays from data.cpp
int PADDED_info[80];
int * const info = PADDED_info+8;
BitBoard setmask[64];
char numfilwhitepawns[8];
char numfilblackpawns[8];
Uri

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 28 June 2004 23:52:57:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Volker Boehm at 28 June 2004 23:27:52:

Movei can crash if you give it an illegal FEN or long games of more than 1000 moves.
After Dann Corbit's post that it is not acceptable I decided to ask Leo to remove it from his site.
I suggest also other programmers that their program suffers from the same problem to do the same and stop do their program freeware(I believe that most of the chess programs suffer from the same problem).
It is time that chess programmers stop supporting viruses and somebody needs to do the first step.
I may release a new version but it will not be in the near future because
I expect fixing the problem of illegal FEN to not be an easy task and in the near future I care more about improving the strength of the program.
Uri

How can anybody profit from this bugs as a chess program does not listen to any ports?
Greetings Mangar

I do not know but see http://f11.parsimony.net/forum16635/messages/67791.htm
I understand that viruses can use chess program and give them illegal output.
chess engines are listening to output from winboard and if some virus give them output that make them crash then it may demage the computer.
Uri

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 29 June 2004 00:03:35:
Als Antwort auf:/In reply to: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 28 June 2004 21:42:56:

It is not automatically a security problem, when a program can crash. We wouldn't have many free chess-engines (an perhaps even not commercial ones), when we demanded, that they never can crash.
Winboard has a buffer overlow problem (at least the version, I tried this with), and can crash. A similar problem had some Fritz interfaces. When sending too long PVs, the GUIs would crash, or do other stupid things. I remember that some Shredder engine crashed when a position had 10 knights. I saw the Fritz 7 GUI crashing *many* times. I could easily reproduce some crashes, by sending output of the engine to it (that was legal according to the UCI protocol - but it really doesn't matter).
I guess most not very simple programs on my HD can crash in one way or the other way. In some really security related applications, buffer overflows are found almost regularily - even after *many* years of developement.
I would be more concerned, that a crashing chess engine can destroy some data on the HD (also even this seems unlikely), than that there will be the danger of a virus infection. How should that happen? There must be somebody, who wants to infect you with the virus. How would he do it? Over Winboard when connected to some ICS?
Regards,
Dieter

[Dan Honeycutt]

Geschrieben von:/Posted by: Dan Honeycutt at 29 June 2004 01:22:06:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dann Corbit at 28 June 2004 23:25:35:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 29 June 2004 01:42:45:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dan Honeycutt at 29 June 2004 01:22:06:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

I think that the assumption should be negative.
The rule is to assume that things are going to be wrong in case of doubt.
I think that other can also know by trying movei and see if it crashes(I know that basically it can crash with wrong castling information and the question if it can crash in the specific case that you mention is not important).
the first task should be to have a function to check for the legality of the FEN including no contradiction between the castling rights and the position.
It can be a common program for all chess programs that need it.
It should also check that the king is not threated from 2 opposite rook directions and if it is not threated from more than 2 directions.
Uri

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 29 June 2004 01:47:51:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 29 June 2004 01:42:45:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

I think that the assumption should be negative.
The rule is to assume that things are going to be wrong in case of doubt.
I think that other can also know by trying movei and see if it crashes(I know that basically it can crash with wrong castling information and the question if it can crash in the specific case that you mention is not important).
the first task should be to have a function to check for the legality of the FEN including no contradiction between the castling rights and the position.
It can be a common program for all chess programs that need it.
It should also check that the king is not threated from 2 opposite rook directions and if it is not threated from more than 2 directions.
Uri

also 2 knight directions and 2 opposite direction in general should not be accepted(attacking the king from 2 bishop directions should not be accepted even if they are not opposite directions).
There are more illegal cases(attacking the king by 2 pawns or by a knight and a pawn should not be accepted and the question if movei can crash because of it is not important because even if it does not crash another program can crash).
Attacking the king by 2 pieces at distance 1 from it a;lso should not be accepted.
Uri
Uri
Uri

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 29 June 2004 01:50:21:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 29 June 2004 01:47:51:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

I think that the assumption should be negative.
The rule is to assume that things are going to be wrong in case of doubt.
I think that other can also know by trying movei and see if it crashes(I know that basically it can crash with wrong castling information and the question if it can crash in the specific case that you mention is not important).
the first task should be to have a function to check for the legality of the FEN including no contradiction between the castling rights and the position.
It can be a common program for all chess programs that need it.
It should also check that the king is not threated from 2 opposite rook directions and if it is not threated from more than 2 directions.
Uri

also 2 knight directions and 2 opposite direction in general should not be accepted(attacking the king from 2 bishop directions should not be accepted even if they are not opposite directions).
There are more illegal cases(attacking the king by 2 pawns or by a knight and a pawn should not be accepted and the question if movei can crash because of it is not important because even if it does not crash another program can crash).
Attacking the king by 2 pieces at distance 1 from it a;lso should not be accepted.
Uri

I can add that attacking the king by a knight and another piece at distance 1 also should not be accepted and it includes the case of attacking the king by a knight and a pawn.
Uri

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 29 June 2004 01:59:04:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 29 June 2004 01:50:21:

I can add that attacking the king by a knight and another piece at distance 1 also should not be accepted and it includes the case of attacking the king by a knight and a pawn.

Uri, you should make a list, and post it here. The above, and the 3 directions are case, I don't check in Yace (it shouldn't hurt Yace either), but I think it could be worthwhile, to at least give a warning. I check (now ...) the other mentioned things. King not to move in check, exactly 2 Ks of opposite color, number of pieces per side

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 29 June 2004 02:06:08:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dan Honeycutt at 29 June 2004 01:22:06:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

There are lots of missing definitions. I fear Uri may have a real pain in the neck to do proper cleanup. Here is an initial crack at it:

/*
From the PGN Standard by Steven J. Edwards:
16.1.3.1: Piece placement data
The first field represents the placement of the pieces on the board.
The board contents are specified starting with the eighth rank and
ending with the first rank. For each rank, the squares are specified
from file a to file h. White pieces are identified by uppercase SAN
piece letters ("PNBRQK") and black pieces are identified by lowercase
SAN piece letters ("pnbrqk"). Empty squares are represented by the
digits one through eight; the digit used represents the count of
contiguous empty squares along a rank. A solidus character "/" is
used to separate data of adjacent ranks.
16.1.3.2: Active color
The second field represents the active color. A lower case "w" is
used if White is to move; a lower case "b" is used if Black is the
active player.
16.1.3.3: Castling availability
The third field represents castling availability. This indicates
potential future castling that may of may not be possible at the
moment due to blocking pieces or enemy attacks. If there is no
castling availability for either side, the single character symbol
"-" is used. Otherwise, a combination of from one to four characters
are present. If White has kingside castling availability, the
uppercase letter "K" appears. If White has queenside castling
availability, the uppercase letter "Q" appears. If Black has
kingside castling availability, the lowercase letter "k" appears.
If Black has queenside castling availability, then the lowercase
letter "q" appears. Those letters which appear will be ordered first
uppercase before lowercase and second kingside before queenside.
There is no white space between the letters.
16.1.3.4: En passant target square
The fourth field is the en passant target square.
If there is no en passant target square then the single character
symbol "-" appears. If there is an en passant target square then is
represented by a lowercase file character immediately followed by a
rank digit. Obviously, the rank digit will be "3" following a white
pawn double advance (Black is the active color) or else be the digit
"6" after a black pawn double advance (White being the active color).
An en passant target square is given if and only if the last move was
a pawn advance of two squares. Therefore, an en passant target square
field may have a square name even if there is no pawn of the opposing
side that may immediately execute the en passant capture.
16.1.3.5: Halfmove clock
The fifth field is a nonnegative integer representing the halfmove
clock. This number is the count of halfmoves (or ply) since the
last pawn advance or capturing move. This value is used for the
fifty move draw rule.
16.1.3.6: Fullmove number
The sixth and last field is a positive integer that gives the fullmove
number. This will have the value "1" for the first move of a game for
both White and Black. It is incremented by one immediately after each
move by Black.
*/

#define MAX_FEN_WIDTH 256
//
// Reading a FEN or EPD string does not have to be stupendously fast,
// but it must be very robust. Therefore, extensive error checks
// should be performed.
//
/*
basic definition in def.h:
typedef unsigned __int64 BitBoard;
Here are the definitions of the global arrays from data.cpp
int PADDED_info[80];
int * const info = PADDED_info+8;
BitBoard setmask[64];
char numfilwhitepawns[8];
char numfilblackpawns[8];
*/
#include
#include
#include
#include
#include
using namespace std;
static int counts(char *s, char c)
{
int count = 0;
assert(s);
while (s) {
if (*s == c)
++count;
s++;
}
return count;
}
typedef struct fen_epd_tag_limits {
char c;
int min_allowed;
int max_allowed;
char *message;
} fen_epd_tag_limits;
static const fen_epd_tag_limits legality[] = {
{'k', 1, 1, "ERROR: Must be exactly one black king."},
{'K', 1, 1, "ERROR: Must be exactly one white king."},
{'r', 0, 10, "ERROR: Must be between 0 and 10 black rooks."},
{'R', 0, 10, "ERROR: Must be between 0 and 10 white rooks."},
{'b', 0, 10, "ERROR: Must be between 0 and 10 black bishops."},
{'B', 0, 10, "ERROR: Must be between 0 and 10 white bishops."},
{'n', 0, 10, "ERROR: Must be between 0 and 10 black knights."},
{'N', 0, 10, "ERROR: Must be between 0 and 10 white knights."},
{'q', 0, 9, "ERROR: Must be between 0 and 9 black queens."},
{'Q', 0, 9, "ERROR: Must be between 0 and 9 white queens."},
{'p', 0, 8, "ERROR: Must be between 0 and 8 black pawns."},
{'P', 0, 8, "ERROR: Must be between 0 and 8 white pawns."},
{'/', 7, 7, "ERROR: Must be exactly 7 row separators."},
{0, 0, 0, "Unexpected refererence to unused array position."}
};
char *validate_piece_placement(char *s)
{
int i = 0;
char *mess = "";
while (legality[i].c) {
int count = counts(s, legality[i].c);
if (count < legality[i].min_allowed || count > legality[i].max_allowed) {
mess = legality[i].message;
return mess;
}
i++;
}
}
char *validate_active_color(char *s)
{
char *error_string;
if (*s == 'w' || *s == 'b')
error_string = "";
else
error_string = "ERROR: active color must be 'w' or 'b'";
return error_string;
}
static const fen_epd_tag_limits castling[] = {
{'k', 0, 1, "ERROR: Must be zero or one black king in castling rights."},
{'K', 0, 1, "ERROR: Must be zero or one white king in castling rights."},
{'q', 0, 1, "ERROR: Must be zero or one black queen in castling rights."},
{'Q', 0, 1, "ERROR: Must be zero or one white queen in castling rights."},
{'-', 0, 1, "ERROR: Must be zero or one 'no castling rights indicator' (-) in castling rights."},
{0, 0, 0, "Unexpected refererence to unused array position."}
};
char *validate_castling_availability(char *s)
{
char *ss = s;
char *error_string = "";
int i = 0;
while (*ss) {
if (*ss != 'K' && *ss != 'k' && *ss != 'Q' && *ss != 'q' && *ss != '-') {
return "ERROR: Only 'K', 'k', 'Q', 'q', and '-' are allowed in castling rights";
}
ss++;
}
while (legality[i].c) {
int count = counts(s, castling[i].c);
if (count < castling[i].min_allowed || count > castling[i].max_allowed) {
return castling[i].message;
}
i++;
}
if (*s == '-') {
if (strlen(s) != 1) {
return "ERROR: If the no castling rights indicator '-' is used, no other symbols may be contained in castling rights.";
}
}
return error_string;
}
char *validate_en_passant_target_square(char *s, char *active_color)
{
char *error_message = "";
if (strcmp(s, "-"))
return error_message;
if (strlen(s) != 2) {
return error_message = "ERROR: e.p. target square must be of the format , . String is not 2 characters.";
}
char file = tolower(s[0]);
if (file != 'a' && file != 'b' && file != 'c' && file != 'd' && file != 'e' && file != 'f' && file != 'g' && file != 'h')
return error_message = "ERROR: e.p. target square must be of the format , . File is out of range.";
int rank = s[1] - '0';
if (*active_color == 'w') {
if (rank != 3)
return error_message = "ERROR: e.p. target square must be of the format , . White to move requires rank of 3.";
} else {
if (rank != 6)
return error_message = "ERROR: e.p. target square must be of the format , . Black to move requires rank of 6.";
}
return error_message;
}

char *validate_halfmove_clock(char *s)
{
int i;
for (i = 0; i < strlen(s); i++)
if (!isdigit(s[i])) {
return "ERROR: Halfmove clock contains a character that is not a digit.";
}
i = atoi(s);
if (i < 0 || i > 99)
return "ERROR: Halfmove clock must be between 0 and 99.";
return "";
}
char *validate_fullmove_number(char *s)
{
int i;
for (i = 0; i < strlen(s); i++)
if (!isdigit(s[i])) {
return "ERROR: fullmove number contains a character that is not a digit.";
}
i = atoi(s);
if (i < 1 || i > 6000)
return "ERROR: fullmove number must be between 1 and 6000.";
return "";
}
/*
NOTICE: This routine calls strtok() on the original FEN/EPD input string.
Therefore, the original input is altered.
*/
int tokenize_position_string(
char str[256], /* Input is unprocessed
* FEN/EPD string */
char **piece_placement,
char **active_color,
char **castling_availability,
char **en_passant_target_square,
char **halfmove_clock,
char **fullmove_number,
char error_string[256]
)
{
char *token;
int no_error = 1;
char *validation_error;
assert(str);
assert(error_string);
error_string[0] = 0;
*piece_placement = NULL;
*active_color = NULL;
*castling_availability = NULL;
*en_passant_target_square = NULL;
*halfmove_clock = NULL;
*fullmove_number = NULL;
token = strtok(str, " ");
if (token) {
*piece_placement = token;
validation_error = validate_piece_placement(*piece_placement);
if (strlen(validation_error)) {
no_error = 0;
strcpy(error_string, validation_error);
return no_error;
}
token = strtok(str, NULL);
if (token) {
*active_color = token;
validation_error = validate_active_color(*active_color);
if (strlen(validation_error)) {
no_error = 0;
strcpy(error_string, validation_error);
return no_error;
}
token = strtok(str, NULL);
if (token) {
*castling_availability = token;
token = strtok(str, NULL);
if (token) {
*en_passant_target_square = token;
validation_error = validate_en_passant_target_square(*en_passant_target_square, *active_color);
if (strlen(validation_error)) {
no_error = 0;
strcpy(error_string, validation_error);
return no_error;
}
token = strtok(str, NULL);
if (token) {
*halfmove_clock = token;
validation_error = validate_halfmove_clock(*halfmove_clock);
if (strlen(validation_error)) {
no_error = 0;
strcpy(error_string, validation_error);
return no_error;
}
token = strtok(str, NULL);
if (token) {
*fullmove_number = token;
validation_error = validate_fullmove_number(*fullmove_number);
if (strlen(validation_error)) {
no_error = 0;
strcpy(error_string, validation_error);
return no_error;
}
} else {
// You may wish to report a
// problem...
// no_error = -1;
// strcpy(error_string, "WARNING:
// Unable to find
// fullmove number in FEN or EPD
// string --
// defaulting to 1");
*fullmove_number = "1";
}
} else {
// You may wish to report a problem...
// no_error = -1;
// strcpy(error_string, "WARNING: Unable
// to find
// halfmove clock/fullmove number data in
// FEN or EPD
// string -- defaulting to 0 1");
*halfmove_clock = "0";
*fullmove_number = "1";
}
} else {
no_error = 0;
strcpy(error_string, "ERROR: Unable to find e.p. target square data in FEN or EPD string");
}
} else {
no_error = 0;
strcpy(error_string, "FATAL ERROR: Unable to find castling availability data in FEN or EPD string");
}
} else {
no_error = 0;
strcpy(error_string, "FATAL ERROR: Unable to find active color data in FEN or EPD string");
}
} else {
no_error = 0;
strcpy(error_string, "FATAL ERROR: Unable to find piece placement data in FEN or EPD string");
}
return no_error;
}

// BUGBUG: Put globals and prototypes here so I could compile
typedef unsigned __int64 BitBoard;
int hply = 0;
int numpieces = 0;
void buildbasicarrays(void);
void pseudostart(void);
int PADDED_info[80];
int * const info = PADDED_info+8;
BitBoard setmask[64];
char numfilwhitepawns[8];
char numfilblackpawns[8];
int numrankwhitepawns[8];
int numrankblackpawns[8];
#define DARKA 0
#define LIGHTA 1
#define PAWN 1
#define BISHOP 2
#define KNIGHT 3
#define ROOK 4
#define QUEEN 5
#define KING 6
void setup(char position[MAX_FEN_WIDTH])
{
int i = 0;
int square = 56;
int last = 63;
char piece;
char *piece_placement;
char *active_color;
char *castling_availability;
char *en_passant_target_square;
char *halfmove_clock;
char *fullmove_number;
char error_string[256] = "";
numpieces = 0; // BUGBUG: DRC I assume this is some global value
buildbasicarrays();
pseudostart();
if (tokenize_position_string(position, &piece_placement, &active_color, &castling_availability, &en_passant_target_square, &halfmove_clock, &fullmove_number, error_string)) {
while (piece_placement[i] && i < (64+7) && numpieces < 33 && numpieces >= 0 && square < 64 && square >= 0) {
assert(i < (64+7) && i >= 0);
if (position[i] < 'A') {
if (position[i] == '/') {
square = last - 15;
last = square + 7;
} else
square += position[i] - '0';
} else {
numpieces++;
if (position[i] > 'Z') {
info[square] = DARKA;
piece = position[i];
} else {
info[square] = LIGHTA;
piece = (char) (position[i] + 'a' - 'A');
}
switch (piece) {
case 'p':
info[square] += PAWN;
pawnBB[color(square)] |= setmask[square];
pawn_files |= (1 < if (color(square) == LIGHT)) {
white_pawn_ranks |= (1 < numfilwhitepawns[fil0(square)]++);
numrankwhitepawns[rank0(square)]++;
} else {
black_pawn_ranks |= (1 < numfilblackpawns[fil0(square)]++);
numrankblackpawns[rank0(square)]++;
}
break;
case 'n':
putpiece(square, KNIGHT);
break;
case 'b':
putpiece(square, BISHOP);
break;
case 'r':
putpiece(square, ROOK);
break;
case 'q':
putpiece(square, QUEEN);
break;
case 'k':
info[square] += KING;
break;
}
addp(square);
square++;
}
i++;
}
side = 0;
if (*active_color == 'b')
side = 1;
generatepinarray();
/* we now consider castling */
castle = 0;
if (*castling_availability != '-')
while (*castling_availability) {
switch (*castling_availability) {
case 'K':
castle++;
break;
case 'Q':
castle += 2;
break;
case 'k':
castle += 4;
break;
case 'q':
castle += 8;
break;
}
castling_availability++;
}
calcheck();
gen();
max_time = 1 0)
hply--;
hply = side + (hply

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 29 June 2004 02:09:31:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dieter Bürßner at 29 June 2004 00:03:35:

It is not automatically a security problem, when a program can crash. We wouldn't have many free chess-engines (an perhaps even not commercial ones), when we demanded, that they never can crash.
Winboard has a buffer overlow problem (at least the version, I tried this with), and can crash. A similar problem had some Fritz interfaces. When sending too long PVs, the GUIs would crash, or do other stupid things. I remember that some Shredder engine crashed when a position had 10 knights. I saw the Fritz 7 GUI crashing *many* times. I could easily reproduce some crashes, by sending output of the engine to it (that was legal according to the UCI protocol - but it really doesn't matter).
I guess most not very simple programs on my HD can crash in one way or the other way. In some really security related applications, buffer overflows are found almost regularily - even after *many* years of developement.
I would be more concerned, that a crashing chess engine can destroy some data on the HD (also even this seems unlikely), than that there will be the danger of a virus infection. How should that happen? There must be somebody, who wants to infect you with the virus. How would he do it? Over Winboard when connected to some ICS?

Indeed. It seems that a very insidious bug could easily be created. And the generation of such a bug will not be difficult. You simply create a rogue engine that sends an evil buffer designed for overrun as a response to some ordinary winboard response.
If Winboard filters it out, will also Arena, and all other Winboard compatible GUIs? I doubt it.
A buffer over-run can do literally anything to your computer.


my ftp site {remove http:// unless you like error messages}

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 29 June 2004 02:23:58:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Dann Corbit at 29 June 2004 02:06:08:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

There are lots of missing definitions. I fear Uri may have a real pain in the neck to do proper cleanup. Here is an initial crack at it:

I did not look at most of it(after all I am trying to define
backward pawns for movei and I have no time for this task(I hope that my last definition is correct but I will need to test it) but I looked at the definitions that I did not give and I can correct them
The right definitions are:
#define DARKA 8
#define LIGHTA 0
#define PAWN 0
#define KNIGHT 1
#define BISHOP 2
#define ROOK 3
#define QUEEN 4
#define KING 5
numpieces is a global varaible.
Uri

[Dan Honeycutt]

Geschrieben von:/Posted by: Dan Honeycutt at 29 June 2004 02:38:02:
Als Antwort auf:/In reply to: Re: I decided to ask Leo to remove movei from his site geschrieben von:/posted by: Uri Blass at 29 June 2004 01:50:21:

what are the dimentions of:
info[]
setmask[]
numfilwhitepawns[]
numfilblackpawns[]

Dann:
Your offer to help Uri is generous but it looks like a formidable task where you need more than just array sizes. ie - what if the fen string contains a "K" in the castle rights section but no rook on h1. Is this something that Movei can handle without a problem, or could it cause a blowup? Only Uri knows all these nuts and bolts.
Dan H.

I think that the assumption should be negative.
The rule is to assume that things are going to be wrong in case of doubt.
I think that other can also know by trying movei and see if it crashes(I know that basically it can crash with wrong castling information and the question if it can crash in the specific case that you mention is not important).
the first task should be to have a function to check for the legality of the FEN including no contradiction between the castling rights and the position.
It can be a common program for all chess programs that need it.
It should also check that the king is not threated from 2 opposite rook directions and if it is not threated from more than 2 directions.
Uri

also 2 knight directions and 2 opposite direction in general should not be accepted(attacking the king from 2 bishop directions should not be accepted even if they are not opposite directions).
There are more illegal cases(attacking the king by 2 pawns or by a knight and a pawn should not be accepted and the question if movei can crash because of it is not important because even if it does not crash another program can crash).
Attacking the king by 2 pieces at distance 1 from it a;lso should not be accepted.
Uri

I can add that attacking the king by a knight and another piece at distance 1 also should not be accepted and it includes the case of attacking the king by a knight and a pawn.
Uri

In my program there is no problem with the king being attacked from 3 or more directions. There is no problem if it gets a fen for the starting position except with the rooks in the middle of the board. There are all sorts of illegal and impossible positions that I don't worry about because the won't cause a crash. If a user wants to set up one of these positions, fine.
On the other hand, 10 queens for a side or bad castling rights could do me in. If the user wants to set up one of these positions, I have to say no.
A fen parser that excludes anything not 100 percent legal would be a lot of work. Most important is to check the things that could cause the program to crash. That was my point to Dann - each program has it's own Achilles' heel and only you know what those are in Movei.
Dan H.