Gunnar Farnebäck gunnar@lysator.liu.se writes:

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.

Apologies. You are quite correct, it's the library that's doing the conversion, and therefore \n and \012 are likely to be treated the same.

[I'm sure I saw using \012 instead of \n recommended somewhere. Can't think where that was now. Ah : must have been a mac thing, where \n is a CR. ]

dd