D array expansion and non-deterministic re-allocation

Steven Schveighoffer schveiguy at yahoo.com
Mon Nov 23 12:18:00 PST 2009


On Mon, 23 Nov 2009 11:10:48 -0500, Leandro Lucarella <llucax at gmail.com>
wrote:

> Steven Schveighoffer, el 23 de noviembre a las 07:34 me escribiste:
>> >Notice that you are using particular implementation detail (MRU
>> >cache) to explain the semantics of D arrays. There is a very
>> >important distinction between language specification and compiler
>> >implementation. Andrei already had to go pretty deep into
>> >implementation to describe arrays and slices: You can't define D
>> >arrays without talking about shared buffers and memory allocation.
>> >I don't think including the description of the MRU cache in the
>> >language specification is the right solution. But I'm afraid an
>> >abstract definition of "stomping" might turn out to be quite
>> >non-trivial.
>>
>> I haven't yet read all the other posts, so someone else may already
>> have pointed this out but...
>>
>> Having an MRU cache makes it so you *don't* have to explain its
>> semantics (or stomping).  Currently there is a paragraph in the spec
>> (complete with example) talking about how stomping can occur, so you
>> can just remove that part.  There is no need to talk about the MRU
>> cache when talking about arrays, that's an implementation detail.  I
>> was pointing it out because you are already used to the current bad
>> implementation :)  I wouldn't even bring up the MRU cache in the
>> book or the spec.  You just say that you can append to an array and
>> it may make a copy of the data if necessary.  It's just like
>> realloc, except safer.
>
> The thing is, with realloc() is less likely that you forget that the data
> can be copied because it returns the new pointer (that can be the same as
> the original pointer). And even in this case, I saw a lot of bugs related
> to realloc() misuse (and I made a couple myself).
>
> With slices is much worse.

realloc is worse.  If I have multiple aliases to the same data, then I  
realloc one of those, the others all can become dangling pointers if the  
runtime decides to move the data.  You also cannot realloc data that's not  
malloc'd but you can append to a slice of non-heap data without issue.

No matter what you do with slice appending in D, you cannot access  
dangling pointers unless you access the slice's ptr field.

Yes, you can run into trouble if you append to a slice and then change the  
original data in the slice, but that is a rare event, and it won't result  
in corrupting memory you didn't already have access to (at least, with the  
MRU cache).

-Steve



More information about the Digitalmars-d mailing list