From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGygN-0003Zm-I3 for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:44:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGygJ-0003YQ-0l for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:44:35 -0500 Received: from [199.232.76.173] (port=50627 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGygI-0003YN-Rv for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:44:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34768) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGygI-0000nh-Nh for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:44:30 -0500 Message-ID: <4B1A9BF4.2090909@redhat.com> Date: Sat, 05 Dec 2009 19:44:20 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B193DA5.6040507@codemonkey.ws> <4B1A9359.8080305@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Markus Armbruster , qemu-devel@nongnu.org, Paul Brook On 12/05/2009 07:28 PM, Blue Swirl wrote: > On Sat, Dec 5, 2009 at 5:07 PM, Avi Kivity 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.