[PATCH v3 6/7] comctl32/listbox: Implement LBS_NODATA for single-selection listboxes

[Gabriel Ivăncescu]

On Wed, Nov 21, 2018 at 7:33 PM Huw Davies <huw at 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 at 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.