qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/7] util: Add UUID API


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH 1/7] util: Add UUID API
Date: Mon, 8 Aug 2016 09:10:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0

Am 08.08.2016 um 08:33 schrieb Fam Zheng:
> On Mon, 08/08 08:30, Stefan Weil wrote:
>> Am 02.08.2016 um 11:18 schrieb Fam Zheng:
>> [...]
>>> +void qemu_uuid_generate(qemu_uuid_t out)
>>> +{
>>> +    /* Version 4 UUID, RFC4122 4.4. */
>>> +    QEMU_BUILD_BUG_ON(sizeof(qemu_uuid_t) != 16);
>>> +    *((guint32 *)out + 0) = g_random_int();
>>> +    *((guint32 *)out + 1) = g_random_int();
>>> +    *((guint32 *)out + 2) = g_random_int();
>>> +    *((guint32 *)out + 3) = g_random_int();
>>
>> I suggest using uint32_t instead of guint32.
>> Up to now, nearly all QEMU code uses the POSIX data types.
> 
> This is merely to keep consistent with the g_random_int() return type.  If the
> two types had any chance to vary (surely they don't), the uint32_t way would
> look like this:
> 
>         *((uint32_t *)out + 0) = (uint32_t)g_random_int();
> 
> So I think the current way is fine.
> 
> Fam
> 

Yes, technically it is fine, and I know that you had chosen
guint32 to match the type returned by the GLIB function.

I have a similar issue with the Windows API which also uses its
own data types. Many software APIs bring their own data types
with them. Up to now, we obviously avoided using guint32
although we are using the GLIB API for several years.

I also noticed (after I had send my comment) that you just have
made a v2 of your series, so I'm sorry that my comment came so
late.

Stefan




reply via email to

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