Pierce Wetter pierce@twinforces.com writes:
Perl on Windows outputs CRLF for \n. Just read this last night in the Perl Cookbook. So if we want twogtp to work on Windows, the gtp protocol has to deal with CRLF at the minimum. Mac perl probably spits out a CR, so the same goes there, except on Mac OS X, which is really unix...
But in perl you can just set the filehandle to binmode and then it should just send/recv exactly what you tell it to...
Someone could write a quick C program to find out what Windows does in C with \n for sure on that platform.
One question is, how would a dos/windows program be speaking to the other end of a gtp channel ? Possibly not through the stdio library, in which case this may not matter. If it sprintf's to a string and then calls a win32 api to send the data along a named pipe, for example, then there should be no conversions taking place. Similarly, if using sockets, send() and recv() operate on buffers of data, and the \n reinterpretation shouldn't be happening here.
ISTR it is difficult to use stdio from a windows gui program : we tried in gnuplot, but it just doesn't seem to have the concept of stdin.
"A newline is a indicated by a single LF. Possible occurences of CR should be discarded on input."
would be difficult to handle. This is in any case the newline convention I would prefer for GTP.
Then it won't work on CR platforms...
There are three cases: CR, LF, CRLF.
There exist platforms which use CR, LF and CRLF for terminating lines in local text files. This doesn't really need to have any bearing on what the gtp protocol does.
Some care needs to taken when sending data, but avoiding \n and text mode on files removes these issues.
I don't know how macos does pipes and things, so I don't really know whether stdio would be involved.
dd
If we want to handle all three, we need an or clause to deal with the CR vs LF case. It seems to me our choices are:
- Handle LF.
- Handle CRLF by ignoring CRs.
- Handle all three by looking for CR | LF and ignoring any extra LF.
I think #2 is worse, because it will mysteriously not work on some platforms. YMMV.
#3 doesn't really seem much more difficult then #2 but it does mean we can't use things like fgets.
Pierce