From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYOeX-0007li-1B for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:54:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYOeV-0007kw-Ua for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:54:40 -0500 Received: from [199.232.76.173] (port=33209 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYOeV-0007ks-Px for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:54:39 -0500 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:56644 helo=akado.ru) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYOeU-0006PR-QY for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:54:39 -0500 Date: Fri, 22 Jan 2010 21:54:20 +0300 (MSK) From: malc Subject: Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present In-Reply-To: Message-ID: References: <20091228134949.GC4908@volta.aurel32.net> <20091228145325.GA7139@shareable.org> <20091229165007.GB18379@shareable.org> <20100121182033.GD28467@shareable.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 22 Jan 2010, Markus Armbruster wrote: > malc writes: > > > On Thu, 21 Jan 2010, Jamie Lokier wrote: > > > >> 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). > >> > > > > My sentiment exactly. > > > > An example: > > > > Dinkum Unabridged Library was certified by Perennial > > (http://peren.com/pages/aboutus_set.htm) to conform > > to ISO/IEC 9899:1999. > > > > Documentation for realloc: > > http://www.dinkumware.com/manuals/?manual=compleat&Search=realloc&page=stdlib.html#realloc > > > > Hallvard B Furuseth analysis fully applies i believe... > > Regardless of whether his analysis applies to this implementation's > documentation or not: what does this implementation actually do? > I'd guess it follows it's own documentation, but i don't have it to check, anyone? -- mailto:av1474@comtv.ru