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

[Markus Armbruster]

malc <address@hidden> writes:

> 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);
[...]
>>
>> 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.

read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer when the size is zero.

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

I can talk standardese, if you prefer :)

malloc() either returns either a null pointer or a pointer to the
allocated space.  In either case, you must not dereference the pointer.

OpenBSD chooses to return a pointer to the allocated space.  It chooses
to catch common ways to dereference the pointer.

Your "p = (void *)-1" is neither a null pointer nor can it point to
allocated space on your particular system.  Hence, it cannot be a value
of malloc() for any argument, and therefore what read() does with it on
that particular system doesn't matter.