I've just started learning D and noticed a bug, but wanted to confirm it here before reporting it.

According to spec: "If the new array length is shorter, the array is not reallocated, and no data is copied. It is equivalent to slicing the array". Contradicted by a trivial program:

void main() {
    int[] arr;
    arr.length = 7;
    arr.length = 6; // not ok -- allocation
    int[] slice = arr[0..5]; // ok -- no allocation
}

-------------------------------------------------------
dmd -profile=gc test.d
(DMD32 D Compiler v2.069.2)
-------------------------------------------------------
bytes allocated, allocations, type, function, file:line
             28               1 int[] D main test.d:3
             24               1 int[] D main test.d:4

On 12/27/2015 02:09 AM, milentin wrote:
> I've just started learning D and noticed a bug, but wanted to confirm it
> here before reporting it.
>
> According to spec: "If the new array length is shorter, the array is not
> reallocated, and no data is copied. It is equivalent to slicing the
> array". Contradicted by a trivial program:
>
> void main() {
>      int[] arr;
>      arr.length = 7;
>      arr.length = 6; // not ok -- allocation
>      int[] slice = arr[0..5]; // ok -- no allocation
> }
>
> -------------------------------------------------------
> dmd -profile=gc test.d
> (DMD32 D Compiler v2.069.2)
> -------------------------------------------------------
> bytes allocated, allocations, type, function, file:line
>               28               1 int[] D main test.d:3
>               24               1 int[] D main test.d:4

I don't understand why that happens. I found one related bug:

  https://issues.dlang.org/show_bug.cgi?id=13750

I can understand that assignment to arr.length cannot be @nogc but I would expect a check against length so that there would be no allocation.

At least there are no copies and .ptr property of the array does not change.

[Several hours later...]

You know what... I bet there is no actual allocation at all. I think what happens is, the code calls GC.realloc(24) and realloc() does not do anything. However, it still reports to the profiler that there was an allocation (attempt).

Can someone verify that please. At least, can someone show where GC.realloc() source is.

Thank you,
Ali

On Sunday, 27 December 2015 at 22:36:32 UTC, Ali Çehreli wrote:
> [Several hours later...]
>
> You know what... I bet there is no actual allocation at all. I think what happens is, the code calls GC.realloc(24) and realloc() does not do anything. However, it still reports to the profiler that there was an allocation (attempt).
>
> Can someone verify that please. At least, can someone show where GC.realloc() source is.
>
> Thank you,
> Ali

I believe it boils down to calling gc.gc.reallocNoSync in druntime: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L603 .

On Sunday, 27 December 2015 at 22:36:32 UTC, Ali Çehreli wrote:
> I don't understand why that happens. I found one related bug:
>
>   https://issues.dlang.org/show_bug.cgi?id=13750
>
> I can understand that assignment to arr.length cannot be @nogc but I would expect a check against length so that there would be no allocation.
>
> At least there are no copies and .ptr property of the array does not change.
>
> [Several hours later...]
>
> You know what... I bet there is no actual allocation at all. I think what happens is, the code calls GC.realloc(24) and realloc() does not do anything. However, it still reports to the profiler that there was an allocation (attempt).
>
> Can someone verify that please. At least, can someone show where GC.realloc() source is.
>
> Thank you,
> Ali

Thanks for the feedback, I have opened https://issues.dlang.org/show_bug.cgi?id=15481.