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
