[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Feb 2013 13:03:19 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: printf warning with uintmax_t
* Jens Gustedt <jens.gustedt@...ia.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
