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
