qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0
Date: Tue, 19 May 2009 12:43:17 -0300
User-agent: Mutt/1.5.18 (2008-05-17)

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:
> > <snip>
> > > > > > >> 
> > > > > > >> 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:
> 
> <quote>
> 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.
> </quote>

We are already running in circles. I will stop arguing about that until
somebody else chimes in.


>
<snip>
> > > > 
> > > > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]