From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHde2-0006MZ-Bj for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:28:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHddx-0006IJ-Q5 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:28:53 -0500 Received: from [199.232.76.173] (port=58120 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHddx-0006Hr-HB for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:28:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10114) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHddx-0005LQ-Bf for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:28:49 -0500 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB7DSmN0029718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Dec 2009 08:28:48 -0500 Message-ID: <4B1D030E.7070703@redhat.com> Date: Mon, 07 Dec 2009 15:28:46 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B193DA5.6040507@codemonkey.ws> <4B1A9359.8080305@redhat.com> <4B1A9811.8020108@codemonkey.ws> <4B1BE153.6070509@collabora.co.uk> <4B1BE691.1010401@redhat.com> <4B1BF1A0.4030002@redhat.com> <4B1C3282.70009@collabora.co.uk> <20091207025156.GD1021@shareable.org> <4B1CCD4F.3030003@collabora.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 12/07/2009 11:55 AM, Paolo Bonzini wrote: >> OTOH, If all it does it log it to a file, theres a fair chance it might >> succeed. > > > Not necessarily, for example fprintf may fail. There _may_ be a fair > chance to succeed if you use write(2) directly, but that's it > basically, and ENOMEM is always there waiting for you... Right, if malloc() failed write(2) is likely to fail as well. More likely, in fact, since malloc() may have unused process memory to draw upon whereas write(2) can only allocate kernel memory. -- error compiling committee.c: too many arguments to function