Dave wrote:
AFAIK VC is doing the correct thing : \n is defined to expand to whatever line ending is appropriate for the platform.
[...]
I think I did mention this feature of \n | \r, and pointed out that any portable implementations of GTP code should use \012 explicitly if they mean a LF character.
[...]
And on mac, \n is CR
\012 is probably safest if you really mean a LF character
I'm almost, but not completely, certain that you are somewhat wrong here. What follows is my understanding, which also could be wrong. It's correct that the C standard doesn't say what numerical value '\n' should have, although ascii LF is a common choice, at least on unix platforms. I'm pretty certain that '\n' does NOT expand to anything like CRLF on dos/windows platforms simply because that is not a single character. It's possible that '\n' has the value ascii CR on MacOS, but that is more than I know about.
The missing step here is that what actually is written to the output is decided by the C library. What in particular is important is whether the FILE being written to has been opened in text mode or in binary mode. On unix systems I don't think this ever makes a difference, but on other platforms it may. On dos/windows platforms, this is where \n (however it is represented) is converted to the CRLF sequence, but only in text mode. Please correct me if I'm wrong about this.
But these are C specific issues and not all that interesting for the definition of the protocol. What I'd like to know, preferrably from people with actual experience of programming on various platforms and in various languages, is whether the newline convention
"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.
(The details on how to portably implement this in C is of course highly interesting to GNU Go, but replies about this should probably be limited to the gnugo list.)
/Gunnar