This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Dec 15 18:55, Joel Sherrill wrote: > > On 12/15/2014 2:13 PM, Corinna Vinschen wrote: > > On Dec 15 12:10, Joel Sherrill wrote: > >> On 12/15/2014 9:14 AM, Corinna Vinschen wrote: > >>> Hi Joel, > >>> > >>> On Dec 14 23:19, Joel Sherrill wrote: > >>>> Hi > >>>> > >>>> I haven't investigated which other targets have this inconsistency yet. > >>>> But the following code gives a printf format warning on i386-rtems but not > >>>> on sparc-rtems. > >>>> > >>>> #include <stdint.h> > >>>> #include <inttypes.h> > >>>> #include <stdio.h> > >>>> > >>>> void f(uintptr_t me) > >>>> { > >>>> printf( "A: %" PRIdPTR " B: %" PRIdPTR "\n", me, 1 - me ); > >>>> } > >>>> > >>>> This is because intptr_t and uintptr_t are defined as just unsigned int > >>>> on sparc but long unsigned int on i386. > >>>> > >>>> $ sparc-rtems4.11-gcc -dM -E - </dev/null | grep INTPTR > >>>> #define __INTPTR_MAX__ 2147483647 > >>>> #define __INTPTR_TYPE__ int > >>>> #define __UINTPTR_MAX__ 4294967295U > >>>> #define __UINTPTR_TYPE__ unsigned int > >>>> $ i386-rtems4.11-gcc -dM -E - </dev/null | grep INTPTR > >>>> #define __INTPTR_MAX__ 2147483647L > >>>> #define __INTPTR_TYPE__ long int > >>>> #define __UINTPTR_MAX__ 4294967295UL > >>>> #define __UINTPTR_TYPE__ long unsigned int > >>>> > >>>> I don't know whether to start sweeping through gcc and try to get > >>>> these all to just unsigned int or add target architecture specific logic > >>>> to fine tune the inttypes.h that newlib has. It looks like the configure.in > >>>> logic I added a few months cleared up a lot of these but not all. > >> [...] > > Re-reading your mail I guess I misunderstood what you wrote. I wrongly > > took it that when gcc uses int, it could use a long constant and vice > > versa. But what you're saying is that the PRI{x}PTR macros are potentially > > wrong because newlib's inttypes.h doesn't take the type into account, > > only the size, right? > > > > I'm not so sure if the GCC guys take over responsibility for that, but > > it might be tricky to get this right. AFAICS, glibc could also create > > error messages. On 32 bit systems it never uses the 'l' length modifier > > for PRI{x}PTR macros, so it should > > > > Maybe it *is* in order to fix that in GCC for the affected targets?!? > Now that I have looked a bit into the GCC side, I think it is kind of > newlib's fault. :) > newlib-stdint.h has this: > > /* Newlib uses the unsigned type corresponding to ptrdiff_t for > uintptr_t; this is the same as size_t for most newlib-using > targets. */ > #define INTPTR_TYPE PTRDIFF_TYPE > #ifndef UINTPTR_TYPE > #define UINTPTR_TYPE SIZE_TYPE > #endif Where are you looking?!? If I look into newlib's HEAD, I see only this in libc/include/stdint.h: #ifdef __INTPTR_TYPE__ #define INTPTR_MIN (-__INTPTR_MAX__ - 1) #define INTPTR_MAX __INTPTR_MAX__ #define UINTPTR_MAX __UINTPTR_MAX__ #elif defined(__PTRDIFF_TYPE__) #define INTPTR_MAX PTRDIFF_MAX #define INTPTR_MIN PTRDIFF_MIN #ifdef __UINTPTR_MAX__ #define UINTPTR_MAX __UINTPTR_MAX__ #else #define UINTPTR_MAX (2UL * PTRDIFF_MAX + 1) #endif #else And this in libc/include/machine/_default_types.h: #ifdef __INTPTR_TYPE__ typedef __INTPTR_TYPE__ __intptr_t; #ifdef __UINTPTR_TYPE__ typedef __UINTPTR_TYPE__ __uintptr_t; #else typedef unsigned __INTPTR_TYPE__ __uintptr_t; #endif #elif defined(__PTRDIFF_TYPE__) typedef __PTRDIFF_TYPE__ __intptr_t; typedef unsigned __PTRDIFF_TYPE__ __uintptr_t; #else typedef long __intptr_t; typedef unsigned long __uintptr_t; #endif The code you pasted above is nowhere to be seen. Also, as far as the definition of the double underscored macros, __INTPTR_MAX__, __INTPTR_TYPE__, etc is concerned, this is GCC territory, not newlib. Am I missing something (again)? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpFbOJwnsMoD.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |