qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends


From: malc
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
Date: Sun, 6 Dec 2009 11:39:39 +0300 (MSK)

On Sun, 6 Dec 2009, Markus Armbruster wrote:

> malc <address@hidden> writes:
>
> > On Sat, 5 Dec 2009, Markus Armbruster wrote:
> >
> >> Anthony Liguori <address@hidden> writes:
> >>
> >> > Markus Armbruster wrote:
> >> >> Commit a7d27b53 made zero-sized allocations a fatal error, deviating
> >> >> from ISO C's malloc() & friends.  Revert that, but take care never to
> >> >> return a null pointer, like malloc() & friends may do (it's
> >> >> implementation defined), because that's another source of bugs.
> >> >>
> >> >> Rationale: while zero-sized allocations might occasionally be a sign of
> >> >> something going wrong, they can also be perfectly legitimate.  The
> >> >> change broke such legitimate uses.  We've found and "fixed" at least one
> >> >> of them already (commit eb0b64f7, also reverted by this patch), and
> >> >> another one just popped up: the change broke qcow2 images with virtual
> >> >> disk size zero, i.e. images that don't hold real data but only VM state
> >> >> of snapshots.
> >> >>
> >> >

[..snip..]


> >
> > P.S. It would be interesting to know how this code behaves under OpenBSD, 
> > with
> >      p = malloc (0);
> >
> > [1] As does, in essence, 
> > http://www.opengroup.org/onlinepubs/7990989775/xsh/read.html
>
> Replace "p = (void *)-1" by "p = NULL" and it works just fine.
>

That's why i asked for somone to run it on OpenBSD:

Quoting 
http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sektion=3&manpath=OpenBSD+Current&arch=i386&format=html

  Allocation of a zero size object returns a pointer to a zero size object.
  This zero size object is access protected, so any access to it will gen-
  erate an exception (SIGSEGV).  Many zero-sized objects can be placed con-
  secutively in shared protected pages.  The minimum size of the protection
  on each object is suitably aligned and sized as previously stated, but
  the protection may extend further depending on where in a protected zone
  the object lands.

> malloc() either returns a valid pointer or NULL, so what read() does for
> other pointers doesn't matter.

Replace "returns" with "should" and this still won't match the wording
of the standard, besides as "read" behaviour on Linux shows following
those are not high on the agenda.

      7.20.3.3  The malloc function

       Synopsis

       [#1]

               #include <stdlib.h>
               void *malloc(size_t size);

       Description

       [#2] The malloc function allocates space for an object whose
       size  is specified by size and whose value is indeterminate.

       Returns

       [#3] The malloc function returns either a null pointer or  a
       pointer to the allocated space.

I don't know what a "valid pointer" in this context represents.

> qemu_malloc() always returns a valid pointer, but that's not even needed
> in this case.
>

--
mailto:address@hidden




reply via email to

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