Let's have a look at Crafty. Given that Bob has always been very much in favour of CECP, and Crafty has been around for a long time, you would expect that things work nicely. Crafty is CECP v2 btw, and doesn't support "usermove".
Crafty requests SAN output in engine answers through "san=1" by the engine at startup. This is one of the very few opportunities where the otherwise pretty horrible two way feature negotiation might make at least some sense, to let's reject this "feature". Of course, Crafty ignores the rejection...
Code: Select all
ERROR. feature san rejected by xboard
Here's what it looks like with the full game move numbering and the omission dots when Black is to move:
Code: Select all
10 416 7 66408 4. ... d4 5. Nb5 Nc6 6. e3 e5 7. exd4 exd4 8. Bc4 Be6 9. Bxe6 fxe6
Then the CECP spec has this: "SCORE is in centi-Pawn units, and the de-facto standard is to report it from the point of view of the side to move." A spec has one job, to define and mandate a standard, and it can't even define the score sign.
Can you guess what Crafty does? Yup, it always prints White's POV for the score. The 416 in the output above is because White is a knight up and Black is to move.
That's usually "solved" in the GUI by forcing the user to tick some config box. If you think about automating that in c-chess-cli for adjudication, there is no box, and the best way is probably to auto-test a position that has a clear advantage for White (like being a rook up), setting Black to move, and see what the score sign is.
You can't even assume that a CECP engine can play more than one game - some will just exit at the end of a game, and you have to start the executable again. So you need to check whether the engine announces "reuse=1" at startup.
My take is that if you want to fully support CECP engines in c-chess-cli, that will be a whole lot of work with unreliable operation in practice.