* printf warning with uintmax_t @ 2013-02-08 22:10 Jens Gustedt 2013-02-08 22:14 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Jens Gustedt @ 2013-02-08 22:10 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 583 bytes --] Hi again, with musl-gcc the following test program produces a bogus warning concerning uintmax_t on my machine (ubuntu amd64) Jens #include <stdio.h> #include <stdint.h> void toto(void) { uintmax_t val = 42; printf("%jX\n", val); } -- :: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ :: :: AlGorille ::::::::::::::: office Nancy : +33 383593090 :: :: ICube :::::::::::::: office Strasbourg : +33 368854536 :: :: ::::::::::::::::::::::::::: gsm France : +33 651400183 :: :: :::::::::::::::::::: gsm international : +49 15737185122 :: [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: printf warning with uintmax_t 2013-02-08 22:10 printf warning with uintmax_t Jens Gustedt @ 2013-02-08 22:14 ` Rich Felker 2013-02-09 8:35 ` Jens Gustedt 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2013-02-08 22:14 UTC (permalink / raw) To: musl On Fri, Feb 08, 2013 at 11:10:39PM +0100, Jens Gustedt wrote: > Hi again, > with musl-gcc the following test program produces a bogus warning > concerning uintmax_t on my machine (ubuntu amd64) > > Jens > > #include <stdio.h> > #include <stdint.h> > > void toto(void) { > uintmax_t val = 42; > printf("%jX\n", val); > } 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). This should probably be fixed, if for no other reason than C++ ABI issues. Any objections? Rich ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: printf warning with uintmax_t 2013-02-08 22:14 ` Rich Felker @ 2013-02-09 8:35 ` Jens Gustedt 2013-02-09 12:03 ` Szabolcs Nagy 0 siblings, 1 reply; 5+ messages in thread From: Jens Gustedt @ 2013-02-09 8:35 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 922 bytes --] 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. Jens -- :: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ :: :: AlGorille ::::::::::::::: office Nancy : +33 383593090 :: :: ICube :::::::::::::: office Strasbourg : +33 368854536 :: :: ::::::::::::::::::::::::::: gsm France : +33 651400183 :: :: :::::::::::::::::::: gsm international : +49 15737185122 :: [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: printf warning with uintmax_t 2013-02-09 8:35 ` Jens Gustedt @ 2013-02-09 12:03 ` Szabolcs Nagy 2013-02-09 13:24 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Szabolcs Nagy @ 2013-02-09 12:03 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: printf warning with uintmax_t 2013-02-09 12:03 ` Szabolcs Nagy @ 2013-02-09 13:24 ` Rich Felker 0 siblings, 0 replies; 5+ messages in thread From: Rich Felker @ 2013-02-09 13:24 UTC (permalink / raw) To: musl On Sat, Feb 09, 2013 at 01:03:19PM +0100, Szabolcs Nagy wrote: > * 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 Indeed. The underlying type of all typedefs is part of the ABI if you're considering C++. > 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__ Actually I believe the current treatment of __WCHAR_TYPE__ is wrong, isn't it? It should not vary between compilers on a given arch/abi combination. I suspect the code in i386 alltypes.h now is leftover cruft from when the type was first fixed, when I didn't understand the ABI requirements well. > 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 I think [u]intmax_t should just be moved back to alltypes.h with the correct per-arch definitions. A related issue is the limit values. Right now, UINTMAX_MAX is just defined as UINT64_MAX, but the type of the latter is wrong (always ULL). We could either move them to bits, use some #ifdef magic to get them right based on the assumption that all archs use the lowest-rank type of the needed size (is this correct?), or if that assumption is incorrect we could just omit the suffixes like ULL and let the compiler choose the appropriate type for the hex constants. This may generate warnings with some bogus gcc versions or modes, though... Rich ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-02-09 13:24 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-08 22:10 printf warning with uintmax_t Jens Gustedt 2013-02-08 22:14 ` Rich Felker 2013-02-09 8:35 ` Jens Gustedt 2013-02-09 12:03 ` Szabolcs Nagy 2013-02-09 13:24 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).