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

           Summary: string append negative integer causes segfault
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrden@gmail.com


--- Comment #0 from Andriy <andrden@gmail.com> 2011-05-13 01:48:27 PDT ---
Digital Mars D Compiler v2.052

$ dmd SpawnBug.d
$ ./SpawnBug
Segmentation fault (core dumped)
$ cat SpawnBug.d
void main(){
    string ret;
    int i = -1;
    ret ~= i;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


kennytm@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm@gmail.com


--- Comment #1 from kennytm@gmail.com 2011-05-13 02:14:37 PDT ---
This may or may not be expected. Appending any non-Unicode (> 0x10ffff)
character will halt the program. In _d_arrayappendcd
(https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L1762,
BTW why this is in rt/lifetime.d?!):

    else if (c <= 0x10FFFF)
    {
        ...
    }
    else
        assert(0);      // invalid utf character - should we throw an exception
instead?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Vladimir <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com


--- Comment #2 from Vladimir <thecybershadow@gmail.com> 2011-05-13 04:14:04 PDT ---
Calling onUnicodeError would be more appropriate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-05-16 10:31:52 PDT ---
Hm... I think in general it is a design flaw to allow int to implicitly cast to dchar.

I think that is the source of the problem.

Going from (d|w)char to the appropriate width integer should be fine, but going the other way seems prone to error.

Note that in lifetime.d, the assert(0) should not lead to a segmentation fault.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #4 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-16 10:44:52 PDT ---
Implicitly converting to the same-size _unsigned_ integral type might be fine, but converting to a signed type would be a narrowing conversion. I'd still argue that converting between any of the character types and any of the integral types should require a cast though simply because they're not only different types, they're different types of types. The character types are for characters and the integral types are for integers. Regardless, no implicit conversion should be permitted when it's a narrowing conversion. Narrowing conversions should require casts.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch


--- Comment #5 from timon.gehr@gmx.ch 2011-05-16 11:01:47 PDT ---
(In reply to comment #3)
> Hm... I think in general it is a design flaw to allow int to implicitly cast to dchar.
> 
> I think that is the source of the problem.
> 
> Going from (d|w)char to the appropriate width integer should be fine, but going the other way seems prone to error.
> 
> Note that in lifetime.d, the assert(0) should not lead to a segmentation fault.

assert(0) emits asm{hlt;} when compiled in release mode. Encountering hlt _is_ a segmentation fault, so this is just fine.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #6 from timon.gehr@gmx.ch 2011-05-16 11:07:36 PDT ---
(In reply to comment #4)
> Implicitly converting to the same-size _unsigned_ integral type might be fine, but converting to a signed type would be a narrowing conversion. I'd still argue that converting between any of the character types and any of the integral types should require a cast though simply because they're not only different types, they're different types of types. The character types are for characters and the integral types are for integers. Regardless, no implicit conversion should be permitted when it's a narrowing conversion. Narrowing conversions should require casts.

How is that "narrowing"? No information is lost.

@Topic:

void main(){
    uint i=-1;  //fine
    dchar c=-1; //compile time error
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-16 11:19:03 PDT ---
dchar is unsigned. int is signed. They don't cover the same range of values. Converting from one to the other in either direction is a narrowing conversion. I expect that the only reason that uint i = -1; compiles is to make it easy to create the unsigned value whose equivalent is -1 or some other reason related to C code. But personally, I don't think that it should compile without a cast, because you cannot represent -1 in a uint.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-05-16 11:26:52 PDT ---
(In reply to comment #6)
> void main(){
>     uint i=-1;  //fine
>     dchar c=-1; //compile time error
> }

Just tried this and it indeed produces an error:

Error: cannot implicitly convert expression (-1) of type int to dchar

So I wonder why this works?  Seems inconsistent:

int i = -1;
dchar c = i;

Also, the reporter's issue seems to be inconsistent with that error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------