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]

Re: printf/inttypes.h warning



On December 16, 2014 2:24:06 AM PST, Corinna Vinschen <vinschen@redhat.com> wrote:
>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)?
>

It is GCC. gcc/config/newlib-stdint.h where GCC defines the types.


>
>Corinna

--joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]