From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6Qkh-0002Pn-9e for qemu-devel@nongnu.org; Tue, 19 May 2009 10:57:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6Qkb-0002Nj-QS for qemu-devel@nongnu.org; Tue, 19 May 2009 10:57:09 -0400 Received: from [199.232.76.173] (port=56844 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6Qkb-0002Ng-F8 for qemu-devel@nongnu.org; Tue, 19 May 2009 10:57:05 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51429) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6Qka-0005X0-S9 for qemu-devel@nongnu.org; Tue, 19 May 2009 10:57:05 -0400 Date: Tue, 19 May 2009 11:56:53 -0300 From: Eduardo Habkost Subject: Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0 Message-ID: <20090519145653.GE4254@blackpad> 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> 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 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 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. -- Eduardo