[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