http://d.puremagic.com/issues/show_bug.cgi?id=9045
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from [email protected] 2012-11-20 05:42:25 PST --- (In reply to comment #1) > See representation on various systems: > > http://en.wikipedia.org/wiki/Newline > > In particular: > On Unix, and Mac OS X: LF (1 char) > On Windows: CR+LF (2 chars) (In reply to comment #5) > Technically speaking, if you don't know which type of line endings a file uses > > [SNIP] Isn't the "line ending" a *file* totally irrelevant here? In the sense that it is a nothing more than the system's *storage* format? On my windows machine, the *strings* I manipulate don't have "\r\n" as a newline, they have '\n'. That's the entire reason there is a "rb" and "r" option when reading a file. If you *do* have an "\r\n" in your stream, then either: * You have an actual a '\r' in your stream, which is then followed by a new line. * You are actually erroneously manipulating a binary payload, which should be of type ubyte[], and should not be using the std.ascii functions with it. Under these circumstance, and following the unicode definition, I'd say: return 0x0A <= c && c <= 0x0D; Is not only correct (for ascii), but any attempt to parse more than 1 character for this info would be incorrect... PS: WTF is \u{D A} -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
