Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

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

 



Am 25.07.2011 12:06, schrieb Stefan Hajnoczi:
> On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity <avi@xxxxxxxxxx> wrote:
>> qemu_malloc() is type-unsafe as it returns a void pointer.  Introduce
>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
>>
>> Signed-off-by: Avi Kivity <avi@xxxxxxxxxx>
>> ---
>>
>> This is part of my memory API patchset, but doesn't really belong there.
>>
>>  qemu-common.h |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/qemu-common.h b/qemu-common.h
>> index ba55719..66effa3 100644
>> --- a/qemu-common.h
>> +++ b/qemu-common.h
>> @@ -186,6 +186,9 @@ void qemu_free(void *ptr);
>>  char *qemu_strdup(const char *str);
>>  char *qemu_strndup(const char *str, size_t size);
>>
>> +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type))))
>> +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type))))
> 
> Does this mean we need to duplicate the type name for each allocation?
> 
> struct foo *f;
> 
> ...
> f = qemu_malloc(sizeof(*f));
> 
> Becomes:
> 
> struct foo *f;
> 
> ...
> f = QEMU_NEW(struct foo);

Maybe we should allow this and make it the usual pattern:

f = qemu_new(typeof(*f));

It's gcc specific, but we already don't care about portability to other
compilers in more places.

On the other hand, how many bugs did we have recently that were caused
by a wrong sizeof for qemu_malloc? As far as I can say, there's no real
reason to do it. I think it's the same kind of discussion as with
forbidding qemu_malloc(0) (except that this time it just won't improve
things much instead of being really stupid).

Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux