Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
May 13, 2011 [Issue 5995] New: string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
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: ------- |
May 13, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 13, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 16, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 16, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 16, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 16, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 16, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
May 16, 2011 [Issue 5995] string append negative integer causes segfault | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andriy | 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: ------- |
Copyright © 1999-2021 by the D Language Foundation