Stefan Weil <s...@weilnetz.de> 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.
[...]
