Reducing array.length triggers reallocation

[Ali Çehreli via Digitalmars-d-learn]

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