hgm wrote: ↑Sat Dec 22, 2018 4:51 pmBut ambiguous semantics isn't the same as 'anything flies' (out of your nose and such...).
Exactly. Even if the behaviour were completely unspecified, it would be better to choose a reasonable implementation. I guess that after years of C/C++ programming, people find this nonsense normal, but actually, it's already bad in C/C++ because most of that undefined behaviour should have been implementation defined anyway. It's certainly no justification to transfer this way of thinking to application level.
E.g. even "go infinite depth 10" would make sense, because it tells you to stop thinking after d=10 is reached, but not print the search result until you receive a 'stop'.
That's how Shredder implements this case, and I've done it the same way.
This 'never stop' is actually one of the most annoying things for developers of UCI engines, BTW.
It has a good rationale. Many engines, mine included, will return right after finding any mate in search without caring whether it is the shortest. If this mate was found in some selective extension, then chances are that there is a shorter one once the base depth reaches this level. In analysis mode, you want to let the engine run longer to see whether it can find the shorter mate. Or, when there is only one legal move, many engines will just do it and return, which is also not what you want in analysis mode.
I can't confirm that it's one of the most annoying or even complicated things when developing a UCI engine. It's like 6 lines of code at the end of the searcher. OK, actually a bit more because that includes a function call, but only because I print search info once per second along with NPS=0 to show the user than no search is happening anymore (Shredder doesn't do this). I could also get away with just waiting infinitely on the abort event to arrive, that would be two lines of code.
Listening to isready in between is not an issue as this has to be handled in parallel to the search anyway, usually in a separate thread.