Re: [RFC, PATCH] C99 format specifiers for fixed-length integer types

[Javier Martín]

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

int64macros.patch
Description: Text Data

signature.asc
Description: Esto es una parte de mensaje firmado digitalmente