Phobos currently allocates one byte more than requested for all but object types (ie. for all array allocations), but I haven't been able to determine the reason for this.  Is there one?  I had thought that perhaps this was to facilitate toStringz conversion except that function no longer checks for an existing null terminator--it simply allocates a new string and copies.  Assuming there's no specific reason for this, it would be nice if the extra byte were not allocated as it inhibits attempts to perform power-of-two sized allocation.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:du2dtk$2htb$1@digitaldaemon.com...
> Phobos currently allocates one byte more than requested for all but object types (ie. for all array allocations), but I haven't been able to determine the reason for this.  Is there one?  I had thought that perhaps this was to facilitate toStringz conversion except that function no longer checks for an existing null terminator--it simply allocates a new string and copies.  Assuming there's no specific reason for this, it would be nice if the extra byte were not allocated as it inhibits attempts to perform power-of-two sized allocation.
>
>
> Sean

I couldn't find the threads about it but Walter said it was to avoid the case when you slice off the end of memory block that exactly fits and then try to resize in-place. The GC tests to see if it can resize in-place by checking that the pointer is at the head of a block. If the blocks all fit perfectly together then the element one after the end of a block is the start of the next block. The only ways out are to either 1) live with it 2) remove inplace resizing or 3) add a one-byte slop at the end of allocations.