printf/inttypes.h warning

[Corinna Vinschen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20141216/1df48580/attachment.sig>