Re: [Xen-devel] [PATCH V2 3/6] [RFC] xen/common: Introduce _xrealloc function

[Jan Beulich <JBeulich@xxxxxxxx>]

On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
>       return p ? memset(p, 0, size) : p;
>   }
>   
> +void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
> +{
> +    void *new_p;
> +
> +    if ( !new_size )
> +    {
> +        xfree(p);
> +        return NULL;
> +    }
> +
> +    new_p = _xmalloc(new_size, align);
> +
> +    if ( new_p && p )
> +    {
> +        memcpy(new_p, p, new_size);
> +        xfree(p);
> +    }
> +
> +    return new_p;
> +}

While I can see why having a re-allocation function may be handy,
explicit / direct use of _xmalloc() and _xzalloc() are discouraged,
in favor of the more type-safe underscore-less variants. I can't
see though how a type-safe "realloc" could look like, except for
arrays. If resizing arrays is all you're after, I'd like to
recommend to go that route rather then the suggested one here. If
resizing arbitrary objects is the goal, then what you suggest may
be the only route, but I'd still be not overly happy to see such
added.

Furthermore you don't even use internals of the allocator: It is
common practice to avoid re-allocation if the requested size fits
within the already allocated block. That's not the least helpful
because in such a case you can't possibly suffer any -ENOMEM
condition.

And finally - please note _xmalloc()'s and _xfree()'s use /
special casing of ZERO_BLOCK_PTR: You absolutely would need to
mirror this here.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel