lucasart wrote:I don't know if the UCI protocol specifies this explicitly, but if it doesn't it's because it assumes the reader isn't retarded. So I will re-explain it for you:
Even if SF could recognize an invalid FEN, SF would write a message, and what is the GUI supposed to do? Nothing in the UCI protocol specifies the format of such an error message, and how it's supposed to be handled by the GUI. It is the assumption of the UCI protocol that the GUI isn't bogous. And it is the intent of the UCI protocol to avoid reinventing wheels in every engine, and factorizing as much as possible in the GUI (eg. input validation, book management, option parsing rather than reading text config files in hardcoded paths like old xboard engines etc.)
Obviously this should be explained to you:
Undefined behavior => crappy software
(And indeed, the UCI specs do not explicitly specify there should be undefined behavior. In fact it is something you just made up yourself.)
Your reasoning is flawed in several respects:
- By supporting features beyond UCI (such as perft), the assumption that a GUI will be used as front-end is obviously non-sensical.
- UCI does actually define a mechanism to present messages to the user: "info string MESSAGE". This could be used to send warnings to the user, which the latter could see when he runs from the command line, and which any compliant GUI would relay to him.
- Even if you want to insist that UCI is highly deficient, and does not allow for such elementary courtesies as error messages, it is still your own choice to use it. That crappiness results from the choice of an inadequate protocol does not make it any less crappy than when it would result from any other bug or design flaw.
#[Chess] 0w>setboard rrrrkr1R/rr1rr3/8/8/8/8/8/6K1 b abcdf -
8r r r r k r R *
7r r r r
6
5
4
3
2
1 K
a b c d e f g h
#[Chess] 0b (f)>perft 6
1 39 0.00 684210.53nps
2 376 0.00 1579831.93nps
3 18105 0.01 3472382.05nps
4 204974 0.04 4935802.35nps
5 11290454 1.78 6325864.74nps
6 135645554 26.89 5043927.64nps
