From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOUw8-0004c0-TJ for qemu-devel@nongnu.org; Fri, 14 Mar 2014 12:26:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOUw2-0003Rc-MA for qemu-devel@nongnu.org; Fri, 14 Mar 2014 12:26:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOUw2-0003RX-DR for qemu-devel@nongnu.org; Fri, 14 Mar 2014 12:26:14 -0400 Message-ID: <53232D9E.2010002@redhat.com> Date: Fri, 14 Mar 2014 17:26:06 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <3096076082478dafe78553ab5cbd8b572904cbc4.1394794127.git.jcody@redhat.com> <20140314153639.GD1985@redhat.com> <20140314155742.GU1346@redhat.com> In-Reply-To: <20140314155742.GU1346@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: Explicitly specify 'unsigned long long' for VHDX 64-bit constants List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" , Peter Maydell Cc: Kevin Wolf , Jeff Cody , QEMU Developers , Stefan Hajnoczi , Alexander Graf On 03/14/14 16:57, Richard W.M. Jones wrote: > On Fri, Mar 14, 2014 at 03:38:55PM +0000, Peter Maydell wrote: >> On 14 March 2014 15:36, Richard W.M. Jones wrote: >>> On Fri, Mar 14, 2014 at 06:50:37AM -0400, Jeff Cody wrote: >>>> On 32-bit hosts, some compilers will warn on too large integer constants >>>> for constants that are 64-bit in length. Explicitly put a 'ULL' suffix >>>> on those defines. >>>> -#define VHDX_FILE_SIGNATURE 0x656C696678646876 /* "vhdxfile" in ASCII */ >>>> +#define VHDX_FILE_SIGNATURE 0x656C696678646876ULL /* "vhdxfile" in ASCII */ >>> >>> I think it's better to use this C99-defined feature (from ): >>> >>> #define VHDX_FILE_SIGNATURE UINT64_C(0x656C696678646876) >> >> Why? It's longer and we barely use it anywhere else >> in the codebase, whereas we use the ULL suffix all >> over the place... > > It's permitted for unsigned long long to be longer than 64 bits. Yes. > The > UINT64_C() macro will always return a 64 bit int constant. That's incorrect, for two reasons: (a) uint64_t (exact-width integer types in general) are optional in C99. See 7.18.1.1 "Exact-width integer types" p3: These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names. I general we can't state that the "UINT64_C() macro will always return a 64 bit int constant", because the C implementation might not even support such a type. (b) UINT64_C() is for "uint_least64_t" (7.18.4.1 Macros for minimum-width integer constants). "uint_least64_t" is a required type (7.18.1.2 Minimum-width integer types). In practice I'd say it doesn't matter which one we use: - ULL suffix is gnu89, - UINT64_C() macro is gnu89, - "unsigned long long" could be wider in general than 64 bits, - "uint_least64_t" too could be wider in general than 64 bits, - for us both results in uint64_t exactly. So the above is a tie, but the ULL suffix is just nicer. (IMHO :)) Laszlo