You can convert to host encoding, gets more interesting if you
have worked with data from 390's.
Anyway here is the Newline reference from Unicode.
http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf#G10213
na
On Thursday, 2 April 2015 at 13:57:32 UTC, Steven Schveighoffer
wrote:
On 4/2/15 9:05 AM, Jens Bauer wrote:
On Thursday, 2 April 2015 at 12:24:22 UTC, Kagamin wrote:
On Thursday, 2 April 2015 at 11:42:50 UTC, Jens Bauer wrote:
On the other hand, if a file was copied to a platform, where
\r = 13
and \n = 10, and the file contains lines ending in 0x0d,
then this
compiler would not be able to build the file.
Where it will fail? It can see extra lines, but those are
whitespace,
the source should compile just fine.
You're right here; because the D compiler does not require
reading
line-by-line.
The line numbers reported will be incorrect, but that's
probably the
worst that can happen.
However, in a case like PPM (Portable Pixmap Format), the
problem is
that when the first \n character is met, the format switches
to binary;
but that will not occur until we've already read a bunch of
bytes from
the binary stream, resulting in the picture being out of sync.
After reading all this thread, I can safely say, I'm OK with D
not targeting these platforms.
In addition, "Not portable" doesn't mean "buildable without any
changes".
Is it not considered a porting activity to just change those
constants for that version of DMD?
And finally, if the files are written for that platform, won't
they have this wonky coding anyway? And if they are files from
another platform which treats \n and \r traditionally, won't
editors on that platform do the same thing with line numbers? I
really see no problem with the way the code is.
-Steve
