digitalmars.D.bugs - [Issue 6504] New: Regression(2.041): "str" ~ [arr] allows string literal to be modified
- d-bugmail puremagic.com (27/27) Aug 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (10/10) Aug 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (18/18) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (21/31) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (11/11) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (16/24) Feb 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (14/14) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (8/8) Feb 04 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
- d-bugmail puremagic.com (9/9) Feb 04 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6504
http://d.puremagic.com/issues/show_bug.cgi?id=6504 Summary: Regression(2.041): "str" ~ [arr] allows string literal to be modified Product: D Version: D1 & D2 Platform: Other OS/Version: Windows Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: clugdbug yahoo.com.au --- Comment #0 from Don <clugdbug yahoo.com.au> 2011-08-16 03:08:19 PDT --- for (int i=0; i<3; ++i) { char[] x2 = "xxx" ~ ['c']; assert(x2[1] == 'x'); x2[1] = 'q'; } The assertion fails the second time through the loop. What happens, is that "xxx" ~ ['c'] becomes a string literal of value "xxxc" and type char[]. Thus, it is modifiable. This code passes on 2.040. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6504 --- Comment #1 from Don <clugdbug yahoo.com.au> 2011-08-16 10:32:58 PDT --- This bug was introduced in this commit, which fixed bug 5852. https://github.com/D-Programming-Language/dmd/commit/5c7c6b51e27d9cd394ddda4f7940cdf9c1610953 This means that "xxx" ~ ['c'] is a string literal of type char[] (that is, it's a _mutable_ string literal). Either this needs to be changed, or else a partial fix of bug 2356 needs to be made. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6504 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |INVALID --- Comment #2 from Walter Bright <bugzilla digitalmars.com> 2012-01-31 21:27:41 PST --- I'm going to argue this is not a bug. While "xxx" is immutable, "xxx"~['c'] is mutable. Otherwise, it would be an error to use it to initialize x2. Hence, x2 can modify it. Since x2 is a reference to the initializer, not a copy of it, the initializer is modified. The spec says that string literals in the source code are immutable, not incidental string literals in the compiler that result from other operations. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6504 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #3 from Don <clugdbug yahoo.com.au> 2012-02-01 02:21:04 PST --- (In reply to comment #2)I'm going to argue this is not a bug. While "xxx" is immutable, "xxx"~['c'] is mutable. Otherwise, it would be an error to use it to initialize x2. Hence, x2 can modify it. Since x2 is a reference to the initializer, not a copy of it, the initializer is modified. The spec says that string literals in the source code are immutable, not incidental string literals in the compiler that result from other operations.Reopened, because in every other respect, it behaves as an immutable string literal. On Linux, the test case causes a segfault -- it's an attempt to modify an read-only literal. On Windows, it's a secret global variable. You can even mark it as pure. I don't think we can afford to have something so simple causing undefined behaviour. Fixing this bug isn't a big deal, btw. Now that I've put an isCtfe flag in array literals, this case can go back to being an ArrayLiteral without hurting CTFE performance. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6504 --- Comment #4 from Walter Bright <bugzilla digitalmars.com> 2012-02-01 14:05:45 PST --- I found out it causes the seg fault after posting last night. I don't quite understand your suggestion. Do you have a fix that can be pulled? I did try just not constant folding "string"~['c'] and letting that be done at runtime, but that caused interpret3.d to fail, as it relies on the constant folder to do that. So I think that can work if you enhance CTFE to handle the "string"~['c'] case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6504 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody puremagic.com |clugdbug yahoo.com.au --- Comment #5 from Don <clugdbug yahoo.com.au> 2012-02-02 04:47:30 PST --- (In reply to comment #4)I found out it causes the seg fault after posting last night. I don't quite understand your suggestion. Do you have a fix that can be pulled?I thought there was an existing pull request, but I was wrong (the closed pull457 is what I was thinking of, it's closely related but a little different).I did try just not constant folding "string"~['c'] and letting that be done at runtime, but that caused interpret3.d to fail, as it relies on the constant folder to do that. So I think that can work if you enhance CTFE to handle the "string"~['c'] case.Yes, I think that I need to create CTFE-specific appender code anyway. It's the only case left where CTFE makes useless copies of array literals. I will work on it tonight. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6504 --- Comment #6 from github-bugzilla puremagic.com 2012-02-03 23:20:55 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5fd81965b2155abd6c5f8bbfcb9d7b1460a36b87 6504 Regression(2.041): "str" ~ [arr] allows string literal to be modified (a) Move slicing functions from interpret.c into constfold.c (b) move existing string ~ [arr] -> string into interpret.c (c) create string ~ [arr] -> [arr] for non-CTFE functions. The CTFE slicing functions are used for the conversion, to avoid code duplication. Fixes bug 6504. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6504 --- Comment #7 from github-bugzilla puremagic.com 2012-02-04 00:57:04 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/467cf6687f60dbb4180df036bd0508b9ce408d19 fix issue 6504, fix issue 7419 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6504 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2012