Re: printf warning with uintmax_t

[Szabolcs Nagy <nsz@port70.net>]

* Jens Gustedt <jens.gustedt@inria.fr> [2013-02-09 09:35:00 +0100]:
> Am Freitag, den 08.02.2013, 17:14 -0500 schrieb Rich Felker:
> > It looks like we're not matching the ABI convention gcc expects, where
> > [u]intmax_t is the lowest-rank type capable of storing the full
> > integer range (i.e. long on 64-bit systems).
> 
> I didn't check how you do this in musl, but for me gcc without any
> includes has
> 
> #define __INTMAX_TYPE__ long int
> 
> so I guess that macro is just what should be taken to match its
> expectations for printf formats. You still could have a fallback for
> compilers that don't provide this. I checked for clang and it does,
> BTW.

tcc, pcc, cparse (the firm frontend) does not define __INTMAX_TYPE__
and clang blindly follows gcc

there may be various possible definitions for intmax_t, assuming
a given abi, and the compiler has no business knowing which one is
choosen by the libc

of course printf format checking, c++ and c11 generics with builtin
intmax_t functions change that

i think it's better if the intmax_t definition is fixed for a given
abi (so libc can define it without consulting the compiler), but
just like with __WCHAR_TYPE__ it may be ifdefed: if __INTMAX_TYPE__
is defined then use that otherwise a default (however that adds an
extra branch in the preprocessor for no good reason: it may change
from compiler to compiler but it should not, the compilers should
agree on something here)

once this is sorted out inttypes.h should be fixed as well