From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6RTs-0000BH-Gb for qemu-devel@nongnu.org; Tue, 19 May 2009 11:43:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6RTn-00004w-Tu for qemu-devel@nongnu.org; Tue, 19 May 2009 11:43:52 -0400 Received: from [199.232.76.173] (port=50403 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6RTn-0008WK-GO for qemu-devel@nongnu.org; Tue, 19 May 2009 11:43:47 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52346) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6RTn-00069l-06 for qemu-devel@nongnu.org; Tue, 19 May 2009 11:43:47 -0400 Date: Tue, 19 May 2009 12:43:17 -0300 From: Eduardo Habkost Subject: Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0 Message-ID: <20090519154317.GF4254@blackpad> References: <20090518221705.GO2079@blackpad> <8763fxvbfk.fsf@pike.pond.sub.org> <87octpnrhr.fsf@pike.pond.sub.org> <20090519142847.GC4254@blackpad> <20090519145653.GE4254@blackpad> 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: malc Cc: Markus Armbruster , qemu-devel@nongnu.org On Tue, May 19, 2009 at 07:23:57PM +0400, malc wrote: > On Tue, 19 May 2009, Eduardo Habkost wrote: > > > On Tue, May 19, 2009 at 06:48:25PM +0400, malc wrote: > > > > > > > > >> > > > > > > >> Can't see what this hunk accomplishes. If we remove it, the loop > > > > > > >> rejects, and we thus execute: > > > > > > >> > > > > > > > > > > Once again, on Linux/GLIBC it will, on AIX it wont. > > > > > > > > Why not? It will. If nb_snapshots is 0, it won't enter the loop. The > > > > problem with that code was the "if (!s->snapshots)" check, not the > > > > qemu_mallocz(0) call. > > > > > > Because qemu_mallocz on AIX will be terminated by oom_check. > > > > That's exactly what the patch prevents from happening. > > And i said as much: > > > Again, it's pointless only with your proposed addition, otherwise > instead of 'could not open disk image' one would get an out of memory > error. > We are already running in circles. I will stop arguing about that until somebody else chimes in. > > > > > > > > > realloc() return value is specified exactly the same way malloc() is: > > > > > > > > "If size is 0, either a null pointer or a unique pointer that can be > > > > successfully passed to free() is returned." > > > > > > Nope, quoting from above page: > > > > > > If size is 0 and ptr is not a null pointer, the object pointed to is > > > freed. > > > > I quoted the above from exactly the same page. > > > > I really hope you are not proposing to make qemu_realloc(p, 0) work but > > qemu_malloc(0) fail, because you would be breaking lots of > > realloc()/malloc() equivalency assumptions. > > That's exactly what i'm proposing. Now, _that_ sounds like a really bad idea. realloc(NULL, n) is specified to be equivalent to malloc(n). I can't prevent you from inventing a new malloc/free API that works differently from every malloc/free implementation out there. All I can say is that this sounds like a really bad idea. -- Eduardo