|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends |
Date: | Sat, 05 Dec 2009 19:44:20 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091203 Fedora/3.0-3.13.rc2.fc12 Thunderbird/3.0 |
On 12/05/2009 07:28 PM, Blue Swirl wrote:
On Sat, Dec 5, 2009 at 5:07 PM, Avi Kivity<address@hidden> wrote:On 12/04/2009 06:49 PM, Anthony Liguori wrote:I still believe that it is poor practice to pass size==0 to *malloc(). I think actively discouraging this in qemu is a good thing because it's a broken idiom.Why? Unless we have a separate array allocator (like C++'s new and new[]), we need to support zero-element arrays without pushing the burden to callers (in the same way that for () supports zero iteration loops without a separate if ()).Running a loop zero or nonzero number of times always has a very clear and precise meaning. A pointer returned from allocating zero or nonzero number of items may be completely unusable or usable, respectively.
Only if you allocate using POSIX malloc(). If you allocate using a function that is defined to return a valid pointer for zero length allocations, you're happy.
I think Laurent's proposal would work. We even could go so far as rename the current function as qemu_malloc_possibly_broken (and adjust callers mechanically) and introduce two new versions, which handle the zero case in clearly advertised ways. Patches would fix the callers to use the correct one
Good idea. Let's name the function that returns a valid pointer qemu_malloc() (since that's what many callers expect anyway, and it's fully backwards compatible), and see who calls qemu_malloc_dont_call_me_with_zero().
Realistically, do we need two variants of malloc/realloc/free, or can we stick with one that works for callers with a minimum of fuss?
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Prev in Thread] | Current Thread | [Next in Thread] |