[Issue 2201] New: Unescaped carriage return ('\r') in string is changed into different EOL.

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jul 7 13:45:17 PDT 2008


http://d.puremagic.com/issues/show_bug.cgi?id=2201

           Summary: Unescaped carriage return ('\r') in string is changed
                    into different EOL.
           Product: D
           Version: 1.029
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla at digitalmars.com
        ReportedBy: business3 at twistedpairgaming.com


The following code demonstrates that a carriage return ("\r") embedded in a
string (at least if it's done with a string mixin) is not retained as a
carriage return ("\r") and is turned into something else (a CRLF ("\r\n") on
Windows, I haven't tested on Unix).

BEGIN FILE testEmbeddedChars.d
module testEmbeddedChars;
import tango.io.Stdout;

char[] makeStrReturnFunc(char[] name, char[] str)
{
        return 
        "char[] "~name~"()"
        "{ return r\""~str~"\"; }";
}

mixin(makeStrReturnFunc("lineFeed",       "\n"));
mixin(makeStrReturnFunc("carriageReturn", "\r"));
mixin(makeStrReturnFunc("tab",            "\t"));
mixin(makeStrReturnFunc("vtab",           "\v"));
mixin(makeStrReturnFunc("formFeed",       "\f"));

void main()
{
        if(lineFeed() != "\n"c)
                Stdout.formatln("lineFeed() is incorrect");

        if(carriageReturn() != "\r"c)
                Stdout.formatln("carriageReturn() is incorrect");

        if(carriageReturn() != "\n"c)
                Stdout.formatln("carriageReturn() is unix EOL");

        if(carriageReturn() != "\r\n"c)
                Stdout.formatln("carriageReturn() is win EOL");

        if(tab() != "\t"c)
                Stdout.formatln("tab() is incorrect");

        if(vtab() != "\v"c)
                Stdout.formatln("vtab() is incorrect");

        if(formFeed() != "\f"c)
                Stdout.formatln("formFeed() is incorrect");
}
END FILE

On Windows, with DMD 1.029, the output is:

BEGIN OUTPUT
carriageReturn() is incorrect
carriageReturn() is win EOL
END OUTPUT

This causes a problem with a utility function I have:

BEGIN CODE
char[] multiTypeString(char[] name, char[] data, char[] access="public")
{
        return 
        access~" T[] "~name~"(T)()"~
        "{"~
        "            static if(is(T ==  char)) { return \""~data~"\"c; }"~
        "       else static if(is(T == wchar)) { return \""~data~"\"w; }"~
        "       else static if(is(T == dchar)) { return \""~data~"\"d; }"~
        "       else static assert(\"T must be char, wchar, or dchar\");"~
        "}";
}

//Sample uses:
mixin(multiTypeString("whitespaceChars", r" \n\r\t\v\f"));
mixin(multiTypeString("winEOL", r"\r\n"));
mixin(multiTypeString("digitEscSeqForAMadeupCustomRegex", r"\\d"));
END CODE

The problem with the above (though it works) is that it requires its user to
doubly-escape the data parameter. This could theoretically be solved with a
CTFE "char[] makeEscaped(char[])", but something like that is bit too complex
for the current CTFE engine to handle. So I'd like to solve it by making the
generated function return a WYSIWYG string of the 'data' parameter (probably a
cleaner solution anyway - and faster to compiler), but this carriage return bug
gets in the way.


-- 



More information about the Digitalmars-d-bugs mailing list