From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NY1eD-0005mA-Py for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:20:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NY1e9-0005gm-6y for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:20:49 -0500 Received: from [199.232.76.173] (port=56319 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NY1e8-0005gd-QO for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:20:44 -0500 Received: from mx20.gnu.org ([199.232.41.8]:18680) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NY1e8-0005EY-Ii for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:20:44 -0500 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NY1e8-0006mR-0Q for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:20:44 -0500 Date: Thu, 21 Jan 2010 18:20:33 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present Message-ID: <20100121182033.GD28467@shareable.org> References: <20091228134949.GC4908@volta.aurel32.net> <20091228145325.GA7139@shareable.org> <20091229165007.GB18379@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Aurelien Jarno Markus Armbruster wrote: > malc writes: > > > On Tue, 29 Dec 2009, Jamie Lokier wrote: > > > >> malc wrote: > >> > On Mon, 28 Dec 2009, Jamie Lokier wrote: > >> > > >> > > Aurelien Jarno wrote: > >> > > > This fixes the loading of a stripped kernel with zero malloc disabled. > >> > > > >> > > *Raises an eyebrow* > >> > > > >> > > Even though there's different perspectives over whether qemu_malloc(0) > >> > > should be allowed, inherited from ambiguity over malloc(0), > >> > > realloc(p,0) has always had a standard, well-defined meaning. > >> > > >> > No. > >> > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b > >> > >> Wow, thanks for that. It's a real surprise. Looks like C99's own > >> rationale is not consistent with itself on the subject, and differs > >> from C90 where the "standard, well-defined meaning" I referred to was > >> defined. > > > > Yep. > > No, this is a misinterpretation of the C99 standard, made possible by > its poor wording. The C99 Rationale is perfectly clear, though: > > 7.20.3.4 The realloc function > > A null first argument is permissible. If the first argument is not > null, and the second argument is 0, then the call frees the memory > pointed to by the first argument, and a null argument may be > returned; [...] The rationale above does not match C89 behaviour. It says the call frees the memory, but it does not forbid the call from then proceeding to do the same as malloc(0) and return a non-NULL pointer. It's quite explicit: a null argument *may* be returned. Which means the rationale does not require realloc(p,0) to do the same as C89, which always frees the memory and doesn't allocate anything. > This is hardly surprising, because anything else would break working C89 > programs, and that would squarely contradict the standard's mission, Understood. But it doesn't really matter what's intended or what's misinterpreted. If there are any significant implementations out there based on the "misinterpretation", or even based on the rationale, that's enough of a reason to not depend on realloc(p,0). -- Jamie