WinBoard terminates game when reading the word draw

[Sven]

Receiving non-compliant input must by necessity result in undefined behavior, or it would be impossible to extend the protocol. What is non-compliant now, could be in the protcol specs next year. If the protocol would guarantee that it was ignored, you would break compatibilty by that, because you will not add a new command for the purpose of being ignored.

I think it is also desirable to hve an opportunity to add undocumented commands, not mentioned in the specs, because they do not completely do what I want yet, or because I want to keep the possibility open to change their behavior. And changing behavior without breaking compatibility is only possible as long as the behavior is still undefined.

"GUI" means "graphical user interface" A chess GUI should never propagate non-compliant input from an engine to the user by showing "undefined behavior". This is bad software engineering. If I were your customer then I would consider switching to a different supplier for that

If you want to extend the protocol then simply do it, and change the implementation of your GUI accordingly. After doing that, your old GUI version is based on the previous protocol spec document version (short "spec version") and the new GUI version on the recent one. Both can specify that the GUI ignores all input lines that are not otherwise covered by the current spec version. In general, you have a model similar to this example:

Spec versions: P1, P2, P3 (this is *not* meant as the "protover" version v1/v2!)

GUIs: GUI-A, GUI-B, GUI-C (e.g. WinBoard, ChessGUI, Arena)

GUI versions and their conformance to spec versions:

GUI-A-v1 conforms to P1
GUI-A-v2 conforms to P2
GUI-A-v3 conforms to P3

GUI-B-v1 conforms to P1
GUI-B-v2 still conforms to P1 (P2 changes not yet implemented)
GUI-B-v3 conforms to P2
GUI-B-v4 conforms to P3

GUI-C-v1 conforms to P1
GUI-C-v2 conforms to P2
GUI-C-v3 still conforms to P2 (P3 changes not yet implemented)

Even if you do not explicitly keep track of spec versions (I would like it if you did, though) the model remains the same. You can extend the protocol, e.g. by a new command or a new parameter for the "feature" command. GUIs not yet implementing that new spec version will still ignore the new command until they upgrade to the new spec version. Where is the problem?

As to the usage of strstr: yes, I think that is bad programming, and could be improved. But making changes just to alter behavior that is not specified in the first place and can only occur due to engines violating the specs does have a lower priority than creating new specified functionality.

No, it is not "bad programming". Using strstr() is correct for detecting substrings while strncmp() is correct for detecting exact matches of the first N characters of a string. In the given case, both are "good programming" but the former is wrong w.r.t. the current spec version. So please, accept the bug and don't beat around the bush!

Regarding your priorities, I doubt that it is a good policy to always prefer creating new functionality (and thereby potentially more bugs) over fixing known existing bugs. Fixing that one here is cheap, and there is no way for anyone to complain about that fix. Talking two days about it but still not doing the fix is not so cheap

Sven

[hgm]

Well, that would force me to specify in detail anything I do. So that is undesirable.

Of course nothing has to stop others from making such specifications. The could for instance make a v2.1 engine-intf.html that would specify that Draw anywhere on the line would be understood as a 1/2-1/2 command, to document the behvior of WinBoard 4.2.7 to 4.4.2. And when I would fix it, they could create a v2.2 spec, where this is changed to only at the beginning of the line.

They would be wasting their time largely, as hardly anyone ever reads documentation, and when they do they probably would not read the correct version f you spread many versions around, or remember an old version while it was already superseeded by a newer one.

And under condition of frequent spec changes, specified behavior becomes in practice undefined behavior, as people could never be sure what specs exactly apply.

I reserve the right to make changes in the way WinBoard treats non-compliant input at any time, without notifying anyone, if that suits me. So having engines send non-compliant commands to WinBoard is ill-advised. Especially for this reason the debug=1 feature was added: it allows the engine to send anything the engine author would like to see printed in the debug file, while remaining fully compliant. So that all non-compliant commands can be reserved for developer. The number of character strings starting with "#" is just as large as that starting with other characters (namely countably infinite), so that seems a pretty fair deal!

[Sven]

Well, that would allow me to specify anything I do. So that is undesirable.

Of course nothing has to stop others from making such specifications. The could for instance make a v2.1 engine-intf.html that would specify that Draw anywhere on the line would be understood as a 1/2-1/2 command, to document the behvior of WinBoard 4.2.7 to 4.4.2. And when I would fix it, they could create a v2.2 spec, where this is changed to only at the beginning of the line.

They would be wasting their time largely, as hardly anyone ever reads documentation, and when they do they probably would not read the correct version f you spread many versions around, or remember an old version while it was already superseeded by a newer one.

And under condition of frequent spec changes, specified behavior becomes in practice undefined behavior, as people could never be sure what specs exactly apply.

I reserve the right to make changes in the way WinBoard treats non-compliant input at any time, without notifying anyone, if that suits me. So having engines send non-compliant commands to WinBoard is ill-advised. Especially for this reason the debug=1 feature was added: it allows the engine to send anything the engine author would like to see printed in the debug file, while remaining fully compliant. So that all non-compliant commands can be reserved for developer. The number of character strings starting with "#" is just as large as that starting with other characters (namely countably infinite), so that seems a pretty fair deal!

I have no clue what you are talking about now.

1. I do not know any other active branch of the WinBoard protocol specification document than the one you are currently maintaining. So what you have written about "others making such specifications" appears to have zero relevance for the topic, provided I did not misunderstand you completely. I was talking about different versions of other WinBoard GUIs, not different branches of the spec.

2. The idea to document WinBoard 4.2.7 to 4.4.2 behavior by changing the spec as you described would indeed be a very bad idea. The spec shall reflect the intended behavior of a family of GUIs, not the actual behavior of one specific GUI implementing the protocol, and furthermore it shall not document existing bugs but focus on specifying what is "correct". Unfortunately the engine-intf.html already contains a mixture between real WB protocol spec and WinBoard/xboard program specific implementation description, although I hope the portion of the latter is small. But the concrete GUI specific part should not be extended further IMO.

3. The handling of non-compliant input as it is specified by the current WB protocol is good w.r.t. what appears how in the debug file, no doubt about that. The debug=1 feature seems to match this requirement very well. So I don't really get the idea behind your sentence: "So having engines send non-compliant commands to WinBoard is ill-advised." Non-compliant input exists, and I think it is best for all involved parties to deal with such input in a consistent manner when it comes to interpretation of input, i.e. beyond the plain copying to the debug file. If the common agreement were that the reaction of a GUI to such input were "undefined" then I would be surprised. I think that most people would expect "ignore" as the normal reaction. You can create a poll about it if you like

I would be very interested in reading how other WB protocol implementations handle
a) non-compliant input in general (apart from the debug=1 aspect),
b) especially the case of the string "Draw" appearing in the middle of a non-compliant input line that does *not* begin with a "#". Is the exception for "Draw" that is mentioned in the WB protocol spec implemented, and if so, is it restricted to the beginning of the line or not?

Sven

[hgm]

Well, I would be surprised if ther GUIs implementing WB protocol would implement it. If I were to write a GUI from scratch, I certainly would not. I consider this part of the engine-intf.html as a description of the peculiarities of WinBoard, and not as a part of the protocol specs.