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

[Avi Kivity <avi@redhat.com>]

On 12/05/2009 07:08 PM, malc wrote:
>
>> What's the impact of such usage?  What would improve for users if it
>> were eradicated?  For developers?
>>
>> I believe the answer the first two questions is "nothing in particular",
>> and the answer to the last one is "hassle".  But I'd be happy to see
>> *specific* examples (code, not hand-waving) for where I'm wrong.
>>
>> I'm opposed to "fixing" something without a real gain, not just because
>> it's work, but also because like any change it's going to introduce new
>> bugs.
>>
>> I'm particularly critical of outlawing zero size for uses like
>> malloc(N*sizeof(T).  These are fairly common in our code.  Having to add
>> special treatment for N==0 is a trap for the unwary.  Which means we'll
>> never be done chasing this stuff.  Moreover, the special treatment
>> clutters the code, and requiring it without a clear benefit is silly.
>> Show me the benefit, and I'll happily reconsider.
>>
>> For a specific example, let's look at the first example from my commit
>> message again: load_elf32(), load_elf64() in hw/elf_ops.h.  "Fix" for
>> its "broken" usage of qemu_mallocz(), shot from the hip, entirely
>> untested:
>>      
> Excellent example, now consider this:
>
>    read$ cat<<  eof | gcc -x c -
>    #define _GNU_SOURCE
>    #include<err.h>
>    #include<unistd.h>
>    #include<stdlib.h>
>    #include<fcntl.h>
>
>    int main (void)
>    {
>        int fd = open ("/dev/zero", 0);
>        int ret;
>        void *p = (void *) -1;
>
>        if (fd == -1) err (1, "open");
>        ret = read (fd, p, 0);
>        if (ret != 0) err (1, "read");
>        return 0;
>    }
>    eof
>    read$ ./a.out
>    a.out: read: Bad address
>
>    

I don't see how this is relevant.  Linux' read(2) may or may not be 
broken, but what does that have to do with breaking callers of 
qemu_malloc() for certain use cases?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.