On Fri, 08/05 08:31, Markus Armbruster wrote:
> 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.
Fair enough. If QEMUUUID wasn't so UNREADABLE, I'd have used it.
Will change to QemuUUID. It's a bit more acceptable to me.
Fam
