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 11:56:53 -0300
User-agent: Mutt/1.5.18 (2008-05-17)

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


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




reply via email to

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