New adapter: std.allocator.quantizer

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Mon May 11 11:06:57 PDT 2015


On 05/11/2015 05:28 PM, Andrei Alexandrescu wrote:
> On 5/10/15 5:08 AM, Timon Gehr wrote:
>> On 05/10/2015 01:48 PM, Timon Gehr wrote:
>>>
>>>
>>> "bool expand(ref void[] b, size_t delta);
>>> Post: !result || b.length == old(b).length + delta     Expands b by
>>> delta bytes. If delta == 0, succeeds without changing b. If b is null,
>>> the call evaluates b = allocate(delta) and returns b !is null.
>>> Otherwise, *b must be a buffer previously allocated with the same
>>> allocator*. If expansion was successful, expand changes b's length to
>>> b.length + delta and returns true. Upon failure, the call effects no
>>> change upon the allocator object, leaves b unchanged, and returns
>>> false."
>>
>> Actually, reading that snippet of the documentation, I notice more
>> problems in the implementation of expand/the documentation of the
>> rounding function.
>>
>> If the rounding function returns a non-zero result for a zero argument,
>> expand can return invalid memory (starting from address 0) if given an
>> empty block 'b'.
>
> Thanks again for the great review.

No problem!

> Just updated quantizer.d, I think I've addressed all points:
>
> https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/quantizer.d
>


Unfortunately,

- If the rounding function is not piecewise constant with one fixed 
point per piece, it can happen that 'allocated >= needed' but 'allocated 
< goodAllocSize(needed)'. Then, the allocated size will be inconsistent 
with goodAllocSize. (This is why I recommended to require the rounding 
function to have this property, which is stronger than monotonicity.)

- If b.ptr is null, then line 113 is bad in case goodAllocSize(0) > 0.



More information about the Digitalmars-d mailing list