Is 79 maximal?

[zullil]

A legal position:

[d]r1b1k2r/1n1n1q1p/1p1p1p1b/p1p1p1p1/P1P1P1P1/1P1P1P1P/Q1N1N1B1/R1B1K2R w KQkq a6

[reflectionofpower]

A legal position:

[d]r1b1k2r/1n1n1q1p/1p1p1p1b/p1p1p1p1/P1P1P1P1/1P1P1P1P/Q1N1N1B1/R1B1K2R w KQkq a6

It pastes in Deep Fritz no problem so why would it not be legal. If it was not it wouldn't fit.

[kbhearn]

I assume you're talking about character length of a FEN string. in your example you're missing the move counter/half move counter and a6 should technically not be listed as EP square as there's no pawn to capture to there but as that's a relatively common error i imagine you should allow it nonetheless.

[zullil]

I assume you're talking about character length of a FEN string.

Correct!

In your example you're missing the move counter/half move counter

Yes, I am omitting the final two fields from consideration.

and a6 should technically not be listed as EP square as there's no pawn to capture to there but as that's a relatively common error i imagine you should allow it nonetheless.

You might be wrong here. At least according to

16.1.3.4: En passant target square

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.

http://kirill-kryukov.com/chess/doc/fen.html

[Adam Hair]

Yes. If a7a5 was the last move, then listing a6 in the en passant field is not an error according to the FEN standard.

[zullil]

Yes. If a7a5 was the last move

For example

[pgn]
[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "White"]
[Black "Black"]
[Result "*"]
[ECO "A00"]

1. g4 g5 2. e4 e5 3. c4 c5 4. a4 Bh6 5. h3 f6 6. f3 d6 7. d3 b6 8. b3 Ne7 9. Bg2 Nec6 10. Ne2 Na5 11. Na3 Nb7 12. Qd2 Nd7 13. Qb2 Qe7 14. Qa2 Qf7 15. Nc2 a5 *
[/pgn]

[Adam Hair]

It seems maximal to me. This string uses the maximum number of characters for each row while using the 4 possible characters for the castle field and includes the en passant field.

[lucasart]

When you're programming a chess engine, or a chess GUI, it's better to be conservative:
* assume people can enter positions that cannot be reached from starting position, or from any chess960 starting position.
* only assumption you can make is that the position is legal, in the sense that it's not already mate or draw by chess rules, and other obvious things like 1 king per
side, etc.

Also, the size of a fen is the least of problems, because you'll never need to store lots of fen in memory.

Based on conservative assumptions:
* 8*8+8 for main part
* 2 for color
* 5 for casting rights
* 3 for en passant
* 4 for full move counter (max 999 moves or 1998 plies)
* 3 for half move clock (cannot be 100 or it has to be mate)
* 1 for the null terminator
That's 90 bytes. Make it 96 for alignment purposes, and so people don't start whining about the 999 moves limit (will now be 999,999,999), and you're there.

[Brunetti]

* 3 for half move clock (cannot be 100 or it has to be mate)

Actually there's no limit on this counter: draw is not automatic and has to be claimed by a player (if he likes so), so a fully legal position may have values higher than 100. Just a detail, this doesn't alter your 96-byte allocation.


Alex

[lucasart]

* 3 for half move clock (cannot be 100 or it has to be mate)

Actually there's no limit on this counter: draw is not automatic and has to be claimed by a player (if he likes so), so a fully legal position may have values higher than 100. Just a detail, this doesn't alter your 96-byte allocation.


Alex

That's some of the most idiotic xboard legacy...

An UCI capable GUI should act as a referee and terminate the game. Same for mate, stalemate, 3-rep, etc.