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:
>> 
>
> [..snip..]
>
>> 
>> read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
>> buffer when the size is zero.
>> 
>
> [..snip..]
>
> Yet under linux the address is checked even for zero case.

Any value you can obtain from malloc() passes that check.

Why does the fact that you can construct pointers that don't pass this
check matter for our discussion of malloc()?

>> > 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.
>> 
>
> Here, i believe, you are inventing artificial restrictions on how
> malloc behaves, i don't see anything that prevents the implementor
> from setting aside a range of addresses with 31st bit set as an
> indicator of "zero" allocations, and then happily giving it to the
> user of malloc and consumming it in free.

Misunderstanding?  Such behavior is indeed permissible, and I can't see
where I restricted it away.  An implementation that behaves as you
describe returns "pointer to allocated space".  That the pointer has
some funny bit set doesn't matter.  That it can't be dereferenced is
just fine.

I'm not sure what your point is.  If it is that malloc(0) can return a
value that cannot be passed to a zero-sized read(), then I fear you have
not made your point.