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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list