[PATCH 1/2] include: Add generic HeapAlloc() wrappers

[Jacek Caban]

Hi Michael,

On 01/21/2018 10:05 PM, Michael Stefaniuc wrote:
> Signed-off-by: Michael Stefaniuc <mstefani at winehq.org>
> ---
> I know that Alexandre and Jacek wanted to work on the HeapAlloc
> wrappers. But I don't remember if I had promised (or not) at the last
> WineConf to dig up my old patch and polish it up and submit it to serve
> as a discussion start point. Anyway, here it is with some explanations.

Thanks for looking at this. This looks mostly good for me. I have a few
suggestions to consider.

> The _nofail variants should not "fail" memory allocations and will raise an
> exception on out of memory conditions.
> heap_alloc_nofail thus will never return NULL.
> heap_realloc_nofail can still return NULL but *only* when the alloc size
> is 0 and thus functions as heap_free. Checking the returned pointer for
> NULL is not needed when the size != 0. And the "assign to temp pointer
> to prevent mem leak on failure" workaround is never needed.

I think that most realloc use cases will use fallible variant (since its
usage usually means that the buffer may grow) and they still need
temporary pointer. How about using something like:
BOOL heap_realloc(void **mem, SIZE_T size)
instead? You could leave passed pointer alone on failure and set it to
new memory on success.

> The _nofail variants should be used only for small allocations that are
> not application driven.
> Preferabely the allocation sizes should be known at compile time.
> Careful when allocating memory for COM and other objects: The main
> object should not be allocated with the _nofail variants. Subsequent
> small allocations in the same object could use the _nofail version.

How about having just heap_alloc as infallible and heap_calloc as
fallible? If you need fallible heap_alloc, you may just pass extra 1
argument to heap_calloc. If you need infallible heap_calloc, then you
know there won't be an overflow and may just multiply arguments.

Thanks,
Jacek