On Wed, Nov 21, 2018 at 7:33 PM Huw Davies huw@codeweavers.com wrote:
On Wed, Nov 21, 2018 at 07:26:05PM +0200, Gabriel Ivăncescu wrote:
On Wed, Nov 21, 2018 at 7:04 PM Huw Davies huw@codeweavers.com wrote:
Plewase do this. Part of the reason this patch is proving difficult is the messy allocation scheme that already exists. Let's tidy that up first. Everything should fall back to a common allocator, once that's done, it becomes easy to alter the size that that will allocate if we shift to using a byte array for the nodata multiselect case.
The only difference I can see is that the custom allocator deals with sizes in bytes, instead of sizes in "number of items", otherwise there's no way to share it. I'll try something like that, hope that's fine.
The common allocator would take number of items, it would then pass that on to heap_realloc() having done the appropriate multiplication.
But that's exactly what InitStorage is currently doing (barring the bug it has, since my bugfix got rejected :-/ ), so why not just use InitStorage?
My concern is: how would that be "common" then for the case where we need to allocate items *without* multiplying by anything?
Consider the case where we need to allocate byte array. If it multiplies by sizeof(LB_ITEMDATA) it will over-allocate by more than an order of magnitude in that case. So it's not so "common" after all and only used in one place (InitStorage) which makes it pointless.