From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6RAg-0000lf-5x for qemu-devel@nongnu.org; Tue, 19 May 2009 11:24:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6RAe-0000hq-GP for qemu-devel@nongnu.org; Tue, 19 May 2009 11:24:01 -0400 Received: from [199.232.76.173] (port=40463 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6RAd-0000gY-Sc for qemu-devel@nongnu.org; Tue, 19 May 2009 11:23:59 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:58558 helo=akado.ru) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6RAd-0001ED-BG for qemu-devel@nongnu.org; Tue, 19 May 2009 11:23:59 -0400 Date: Tue, 19 May 2009 19:23:57 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0 In-Reply-To: <20090519145653.GE4254@blackpad> Message-ID: References: <1242678676-19439-1-git-send-email-ehabkost@redhat.com> <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 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Markus Armbruster , qemu-devel@nongnu.org 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. > > > > > > > > > > > > And FWIW despite behaviour of malloc(0) being marked as implementation > > > > defined i have sa far was unable to find any documentaiton (Linux man > > > > pages, GLIBC info files) witht the actual definition, unlike on AIX > > > > where man pages make it crystal clear what happens. > > > > > > You don't need to have the exact behavior defined, as long as: > > > > I certainly don't, the standard certainly says the implementation is > > obliged to document it, that's what seprates implementation-defined > > from unspecified behaviour. > > > > > 1) You call free(p) later > > > 2) You don't dereference the returned pointer (just like you can't > > > dereference p[n] on a malloc(n) block) > > > 3) You don't assume anything about the returned value when size==0 > > > > > > My point is that this is valid malloc() usage, and there may be existing > > > qemu code relying on that, and I don't see any reason to put a trap for > > > code that would be valid malloc()/free() usage. > > > > Okay, at this point we both expressed our points of view and have to > > agree to disagree. > > Agreed. > > > > > > > > > > > There is nothing implementation defined about realloc(whatever, 0), it > > > > has a defined meaning in POSIX: > > > > http://opengroup.org/onlinepubs/007908775/xsh/realloc.html > > > > > > > > So it doesn't use 1. > > > > > > > > > > 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. -- mailto:av1474@comtv.ru