www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5995] New: string append negative integer causes segfault

reply d-bugmail puremagic.com writes:
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



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: -------
May 13 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995


kennytm gmail.com changed:

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



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: -------
May 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995


Vladimir <thecybershadow gmail.com> changed:

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



---
Calling onUnicodeError would be more appropriate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995


Steven Schveighoffer <schveiguy yahoo.com> changed:

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



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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995


timon.gehr gmx.ch changed:

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





 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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995






 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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995




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: -------
May 16 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5995




11:26:52 PDT ---


 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: -------
May 16 2011