Michel wrote: ↑
Sat Dec 12, 2020 10:43 am
There is a universal consensus, outside computer chess apparently, that a program should always handle illegal input gracefully. Would you want ld to crash if it does not recognize a file format?
I'm not aware of such a concensus for modules that are designed to work together. A program is not supposed to call free() twice on the same pointer. The C library is free to crash on the second free(). There are many such examples.
If you feed scripts you retrieve from the internet to the bash shell, you run the risk of wiping out your system, even if bash zealously checks the validity of the input. bash is dangerous, so use with care. A UCI chess engine is dangerous, too. Don't use it without a GUI unless you know what you're doing.
I think the real problem we have here is that the UCI spec is not a spec.
There is another point good which has already been mentioned. Since the concept of a legal chess position is not well defined (can we have 10 queens? 20? black and white pawns all on the 7th rank?) it seems better to let the engine decide if it can handle a fen and return an error (info string) if this is not so.
The concept of a legal chess position is well defined ("can occur in a legal game of chess"). But indeed it can be tricky to verify this.
Luckily, the "unreachable" positions with normal numbers of pieces and pawns are unlikely to pose a problem for any chess engine.
I suspect the trickiest positions are those with an in-check pattern that cannot legally occur, as the engine might make assumptions when generating evasions that are not valid in the illegal position. An example is Lc0, which can get confused if the king is attacked by two pawns at once:
https://github.com/LeelaChessZero/lc0/i ... -691946095
But still, this example is easily detected once you're aware of it.
What is missing is a clear statement in the "spec" what positions are supposed to be accepted. Then GUIs know what to check for and engine authors know what assumptions about the position they can make.