• Sean Kelly (9/9) Feb 28 2006 Phobos currently allocates one byte more than requested for all but
• Ben Hinkle (9/18) Feb 28 2006 I couldn't find the threads about it but Walter said it was to avoid the...

Sean Kelly <sean f4.ca> writes:

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

"Ben Hinkle" <bhinkle mathworks.com> writes:

"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.