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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 1/7] util: Add UUID API
Date: Mon, 08 Aug 2016 12:52:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Stefan Weil <address@hidden> writes:

> 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();

Why would you need to cast the value of 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.

Yep.  A few uses have crept in here and there, and I hate every one of
them.

[...]



reply via email to

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