Well, I'll try to address you both at once... Let me say that seeing more messages arrive with fresh arguments as I tried to build a coherent response was distressing ;)
-- Pavel, you are right. I recognize I've gone overboard trying to be the paladin of standards, and thus I'd like to withdraw most of the patch. The only part that is useful and might someday become necessary is that dealing with 64-bit integers. In particular, if and when mingw64 support is added, for the reasons stated before. You could argue that we could just use "long long" and its format specifiers for all 64-bit integers everywhere, since it has that length in all supported platforms. However, we have no guarantees this will continue to be so in the future even for our currently supported platforms, and GCC 5.0 might as well have a 128-bit "long long" (MIPS already has an uint128_t), so making printf extract 16 bytes with "%ll" and give it only 8 with an uint64_t argument could be the kind of fun that takes a programmer hours to debug. With the reduced version of the patch I'm putting forward, such a (hypothetical, indeed) change will only impact types.h, while otherwise many source files will need to be modified in a hunt for "%ll"s and their variations. We can consider "lower" types safe since the autopromotion rules will keep the compiler happy even if int becomes 64-bit. -- Vladimir, I've followed your advice and restored the names for the remaining macros in this new patch. I'm open to any compromise between the GRUB_ convention and the need for less verbosity, given that 64-bit numbers are used widely throughout the code base. Conventions are just ways to make the life of us coders easier, but, without showing disrespect for them, they are not dogma. We must be ready to shove them apart if they get in the way. Respect to the utility of the [U]INTn_C(x) macros, they append the required modifiers to make sure the compiler interprets x as an [u]intn_t constant. For example, UINT64_C(1) -> 1uL in my amd64 Ubuntu box, but 1uLL in my WinXP Pro x64 box with mingw64 gcc. I agree that adding them goes outside the scope of the announced "format specifiers", but one without the other is pretty much useless in most real use cases, as I noticed when trying to use my initial patch in real GRUB code. -- -- Lazy, Oblivious, Recurrent Disaster -- Habbit
Index: include/grub/types.h =================================================================== --- include/grub/types.h (revision 2440) +++ include/grub/types.h (working copy) @@ -64,8 +64,14 @@ typedef int grub_int32_t; #if GRUB_CPU_SIZEOF_VOID_P == 8 typedef long grub_int64_t; +#define GRUB_PRIi64 "li" +#define GRUB_PRId64 "ld" +#define GRUB_INT64_C(x) (x ## L) #else typedef long long grub_int64_t; +#define GRUB_PRIi64 "lli" +#define GRUB_PRId64 "lld" +#define GRUB_INT64_C(x) (x ## LL) #endif typedef unsigned char grub_uint8_t; @@ -73,8 +79,18 @@ typedef unsigned grub_uint32_t; #if GRUB_CPU_SIZEOF_VOID_P == 8 typedef unsigned long grub_uint64_t; +#define GRUB_PRIu64 "lu" +#define GRUB_PRIo64 "lo" +#define GRUB_PRIx64 "lx" +#define GRUB_PRIX64 "lX" +#define GRUB_UINT64_C(x) (x ## UL) #else typedef unsigned long long grub_uint64_t; +#define GRUB_PRIu64 "llu" +#define GRUB_PRIo64 "llo" +#define GRUB_PRIx64 "llx" +#define GRUB_PRIX64 "llX" +#define GRUB_UINT64_C(x) (x ## ULL) #endif /* Misc types. */
signature.asc
Description: Esto es una parte de mensaje firmado digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
