From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWiAP-0003oN-Lz for qemu-devel@nongnu.org; Mon, 08 Aug 2016 06:52:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWiAN-0003hi-Lu for qemu-devel@nongnu.org; Mon, 08 Aug 2016 06:52:20 -0400 From: Markus Armbruster References: <1470129518-21087-1-git-send-email-famz@redhat.com> <1470129518-21087-2-git-send-email-famz@redhat.com> <78def4e2-aec9-d7c7-6e35-4a6c9da23057@weilnetz.de> <20160808063317.GA24378@al.usersys.redhat.com> Date: Mon, 08 Aug 2016 12:52:06 +0200 In-Reply-To: (Stefan Weil's message of "Mon, 8 Aug 2016 09:10:21 +0200") Message-ID: <877fbrfs89.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 1/7] util: Add UUID API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Fam Zheng , kwolf@redhat.com, qemu-block@nongnu.org, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, pbonzini@redhat.com, mreitz@redhat.com Stefan Weil 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. [...]