From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6Y8R-0004FP-LK for qemu-devel@nongnu.org; Tue, 19 May 2009 18:50:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6Y8N-0004FC-1b for qemu-devel@nongnu.org; Tue, 19 May 2009 18:50:11 -0400 Received: from [199.232.76.173] (port=38354 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6Y8M-0004F9-Ss for qemu-devel@nongnu.org; Tue, 19 May 2009 18:50:06 -0400 Received: from mail2.shareable.org ([80.68.89.115]:53990) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M6Y8M-0005pW-CA for qemu-devel@nongnu.org; Tue, 19 May 2009 18:50:06 -0400 Date: Tue, 19 May 2009 23:49:54 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0 Message-ID: <20090519224954.GF3986@shareable.org> References: <87octpnrhr.fsf@pike.pond.sub.org> <20090519142847.GC4254@blackpad> <20090519145653.GE4254@blackpad> <20090519154317.GF4254@blackpad> <20090519203223.GC3986@shareable.org> <1242770959-sup-998@blackpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1242770959-sup-998@blackpad> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Markus Armbruster , Qemu Development List Eduardo Habkost wrote: > Excerpts from Jamie Lokier's message of Tue May 19 17:32:23 -0300 2009: > > Eduardo Habkost wrote: > > > Now, _that_ sounds like a really bad idea. realloc(NULL, n) is specified > > > to be equivalent to malloc(n). > > > > No it isn't. You can't make that substitution. > > > > In the case where n == 0, realloc(NULL, n) is guaranteed to not > > allocate anything and return NULL, whereas malloc(n) does not > > guarantee that and in fact doesn't do that on a lot of implementations. > > http://opengroup.org/onlinepubs/007908775/xsh/realloc.html > > "If ptr is a null pointer, realloc() behaves like malloc() for the > specified size." > > "If size is 0, either a null pointer or a unique pointer that can be > successfully passed to free() is returned." Oh. Thanks! I stand corrected; sorry for propagating misinformation. The relevant part in the standard which makes the above not contradict realloc's freeing behaviour, is "if size is 0 and __ptr is not a null pointer__, the object pointed to is freed." All this creates a different problem, unfortunately: If you do: p = malloc(n) /* Arbitrary n, could be zero. */ free(p) it works, but p = realloc(oldp, n) /* Arbitrary n, could be zero. */ realloc(p, 0) is not guaranteed to free the allocated block, if n == 0 && p == NULL. realloc(p, 0) is not equivalent to free(p) in this problem cases. Which is IMHO another reason to either forbid n == 0, or warn about it, or change it unambiguously to n == 1 in the qemu_ wrappers. While we're here, the C language FAQ adds: Q: Is it legal to pass a null pointer as the first argument to realloc? Why would you want to? A: ANSI C sanctions this usage (and the related realloc(..., 0), which frees), although several earlier implementations do not support it, so it may not be fully portable. -- Jamie