This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
inttypes.h on x86-64
- From: "Neal H. Walfield" <neal at walfield dot org>
- To: newlib at sources dot redhat dot com
- Date: Sat, 17 Jan 2009 21:41:06 +0100
- Subject: inttypes.h on x86-64
I'm using newlib on my OS, which I am porting to x86-64. When using
Newlib's inttypes.h file, I get, what I think are, gratuitous
warnings. I think this is because in libc/include/stdint.h, newlib
defines int64_t and uint64_t as follows:
#if __have_long64
typedef signed long int64_t;
typedef unsigned long uint64_t;
#define __int64_t_defined 1
#elif __have_longlong64
typedef signed long long int64_t;
typedef unsigned long long uint64_t;
#define __int64_t_defined 1
#elif __STDINT_EXP(INT_MAX) > 0x7fffffff
typedef signed int int64_t;
typedef unsigned int uint64_t;
#define __int64_t_defined 1
#endif
however, libc/include/inttypes.h reverses the if:
/* 64-bit types */
#if __have_longlong64
#define __PRI64(x) __STRINGIFY(ll##x)
#define __SCN64(x) __STRINGIFY(ll##x)
#elif __have_long64
#define __PRI64(x) __STRINGIFY(l##x)
#define __SCN64(x) __STRINGIFY(l##x)
#else
#define __PRI64(x) __STRINGIFY(x)
#define __SCN64(x) __STRINGIFY(x)
#endif
As both __have_long64 and __have_longlong64 are defined as one
(according to gcc -E -dM), this means that the standard 64-bt types
are longs but "ll" format modifier is used.
I experienced this problem using Newlib 1.16.0, however, I have
visually confirmed that this is also the case for current cvs.
Glibc appears to use long for uint64_t on 64-bit systems (i.e, the
same as newlib). Thus, I suspect that the right change is to
rearrange the if's in <inttypes.h>.
Thanks,
Neal