[Issue 9045] Feature request for std.asscii => function isNewline
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue Nov 20 05:42:27 PST 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9045
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra at gmail.com
--- Comment #7 from monarchdodra at gmail.com 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: -------
More information about the Digitalmars-d-bugs
mailing list