[Issue 2093] string concatenation modifies original (page 2)

November 22, 2008

[Issue 2093] string concatenation modifies original

Posted by d-bugmail
in reply to d-bugmail

Permalink

d-bugmail

Posted in reply to d-bugmail

Permalink

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


schveiguy@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Comment #8 from schveiguy@yahoo.com  2008-11-22 09:44 -------
Note that this behavior is defined in the spec.  See http://www.digitalmars.com/d/2.0/arrays.html#resize

"To maximize efficiency, the runtime always tries to resize the array in place to avoid extra copying. It will always do a copy if the new size is larger and the array was not allocated via the new operator or a previous resize operation.

This means that if there is an array slice immediately following the array being resized, the resized array could overlap the slice"

The fact that it violates invariantness is a side effect that Walter has not yet dealt with.  There have been proposals to fix this, two of which I have proposed:

1. As you said, store the requested length along with the block length in the
GC.  Only appending to an array that ends at the end of the allocated memory
will realloc in place.  Original proposal:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=63146

Note nobody responded to this one

2. Store the length of the allocated array in the first element of the array.
Then modify the meaning of the length member of the array struct to flag
whether it is pointing to the beginning of the array or not.  Original
proposal:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77437

Some people had questions, but nobody proved the proposal wouldn't work.

I don't think Walter is interested in fixing this issue, as it has been a 'feature' for a while, and he never has responded positively to any decent proposals to fix this.


--

http://d.puremagic.com/issues/show_bug.cgi?id=2093 smjg@iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Comment #9 from smjg@iname.com 2008-11-22 10:39 ------- Steven, you have no authority to mark this WONTFIX. --

http://d.puremagic.com/issues/show_bug.cgi?id=2093 schveiguy@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy@yahoo.com Severity|normal |enhancement Keywords|wrong-code | ------- Comment #10 from schveiguy@yahoo.com 2008-11-22 12:42 ------- Sorry, I was thinking wontfix because the compiler functions as designed. I marked it as an enhancment instead. Removing wrong-code keyword also, as this is intended behavior. --

http://d.puremagic.com/issues/show_bug.cgi?id=2093 smjg@iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Keywords| |accepts-invalid, spec ------- Comment #11 from smjg@iname.com 2008-11-22 13:34 ------- So the problem is that it _always_ leaves the decision to resize in place or reallocate to the runtime. The only way in which this can coexist with the principle of invariant is that it is illegal to increase the length of a const/invariant array. Therefore, going by the current spec, the bug is that DMD accepts the code. --

http://d.puremagic.com/issues/show_bug.cgi?id=2093 ------- Comment #12 from ddparnell@bigpond.com 2008-11-22 14:52 ------- It seems to me then that this is a design choice - does the string length belong to the string or to the reference? For slices it must be the reference but for arrays? hmmm... Curently in D, a dynamic array and a slice are indistinguishable and I'm not so sure that should be the case. There are good arguments for the current design and also for the separation of slices and dynamic arrays. Common sense seems to say that if I change the length of a string that therefore every other reference to the same string should also honour the new length, and that this should also have no effect on previously captured slices of the string. --

http://d.puremagic.com/issues/show_bug.cgi?id=2093 ------- Comment #13 from schveiguy@yahoo.com 2008-11-22 16:31 ------- (In reply to comment #12) > It seems to me then that this is a design choice - does the string length belong to the string or to the reference? For slices it must be the reference but for arrays? hmmm... Curently in D, a dynamic array and a slice are indistinguishable and I'm not so sure that should be the case. There are good arguments for the current design and also for the separation of slices and dynamic arrays. > > Common sense seems to say that if I change the length of a string that therefore every other reference to the same string should also honour the new length, and that this should also have no effect on previously captured slices of the string. Arrays should not be typed differently than slices IMO, they should be able to be passed to the same functions. I think one of the two solutions I proposed would place the 'allocated length' of an array on the heap with the array data, thereby having the length stored in a shared location. Slices should respect this length, and if they cannot see the length, they should be reallocated as a full-blown array. --

http://d.puremagic.com/issues/show_bug.cgi?id=2093 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #15 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-03-16 19:55:38 PDT --- This is fixed by the patch in bug 3637. It is in dmd 2.041. Compiling the attached file results in the desired output. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums