Eric Blake <ebl...@redhat.com> writes:
> On 08/04/2016 12:58 PM, Stefan Weil wrote:
>> Hi,
>>
>> On 08/02/16 11:18, Fam Zheng wrote:
>>> The QEMU UUID api, including the data structure (qemu_uuid_t), is fully
>>> compatible with libuuid. Use it, and remove the unused code.
>>>
>>> Signed-off-by: Fam Zheng <f...@redhat.com>
>>> ---
>>> block/vdi.c | 49 ++++++++++---------------------------------------
>>> 1 file changed, 10 insertions(+), 39 deletions(-)
>>>
>
>>> @@ -182,10 +153,10 @@ typedef struct {
>>> uint32_t block_extra; /* unused here */
>>> uint32_t blocks_in_image;
>>> uint32_t blocks_allocated;
>>> - uuid_t uuid_image;
>>> - uuid_t uuid_last_snap;
>>> - uuid_t uuid_link;
>>> - uuid_t uuid_parent;
>>> + qemu_uuid_t uuid_image;
>>> + qemu_uuid_t uuid_last_snap;
>>> + qemu_uuid_t uuid_link;
>>> + qemu_uuid_t uuid_parent;
>>
>> As far as I remember, _t should be avoided because that postfix is
>> reserved by POSIX. Should we use qemu_uuid, or can we ignore POSIX
>> because the type name uses the qemu_ prefix?
>
> Correct that POSIX reserved all _t (which is a bit broad, oh well), and
> also correct that we can take the risk of using it anyways (but if POSIX
> ever standardizes something, we get to keep both of our broken pieces).
>
>
>> Either with qemu_uuid_t or with qemu_uuid:
>
> I thought our coding standard preferred QemuUUID or something similar in
> camelcase, rather than lower case.
Correct. It's ugly (in my opinion), but we should stick to it, so it's
at least consistently ugly.
> But now we are just painting a
> bikeshed, so I won't strongly object.
I'd prefer QemuUUID.
