[Issue 2093] string concatenation modifies original

[d-bugmail at puremagic.com]

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


schveiguy at yahoo.com changed:

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




------- Comment #8 from schveiguy at 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.


--