On 08/14/2010 02:05 PM, Daniel P. Berrange wrote:
> It sounds like it might have some appeal for reducing some of the
user's
> book-keeping, but would require a careful audit of code to safely match
> VIR_ALLOC_N exactly with VIR_FREE_N. Thoughts on this approach?
The #1 goal of the memory allocation APIs is to make it hard to make
programming mistakes. Having a VIR_FREE and VIR_FREE_N somewhat
compromises that goal, for only a small convenience, so I don't think
we need to go down that route.
Thanks for the feedback. I agree with ditching the idea of VIR_FREE_N
and any notion of storing the allocation size as part of the array - too
much complexity to make it easier to write safe programs.
Now back to the question in my original cover letter: does VIR_RESIZE_N
look worthwhile, or should I confine my rework of VIR_REALLOC_N to just
use VIR_EXPAND_N?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org