Re: inttypes.h bug leads to inconsistent warnings cross platform

[Jeff Johnston <jjohnstn at redhat dot com>]

I can't speak to what gcc has or can do, but if the problem can't be solved
by using gcc macros, then perhaps this is something for a compilation
configuration test and setting a macro in newlib.h which could then be used in
inttypes.h to do the right thing for the end-user.

-- Jeff J.

----- Original Message -----
> From: "Joel Sherrill" <joel.sherrill@oarcorp.com>
> To: newlib@sourceware.org, "Joseph Myers" <joseph@codesourcery.com>
> Sent: Wednesday, September 10, 2014 3:09:07 PM
> Subject: Re: inttypes.h bug leads to inconsistent warnings cross platform
> 
> Adding Joseph Myers since newlib-stdint.h appears to have
> originated with him.
> 
> I dug through the gcc source and newlib-stdint.h. The targets
> with warnings define SIZE_TYPE to "long unsigned int" instead
> of just "unsigned int". newlib-stdint.h assumes it can use
> SIZE_TYPE for the UINTPTR_TYPE which by itself is probably OK
> but inttypes.h can't detect when it is long unsigned or just
> int unsigned and thus can't provide the correct PRIxPTR value.
> 
> Does anyone have any ideas on how to address this? Is there some
> piece of info from gcc now to for inttypes.h to make the right
> selection? Or can gcc provide another cpp macro which would help?
> 
> Thanks.
> 
> On 9/5/2014 9:37 AM, Joel Sherrill wrote:
> > Hi
> >
> > This code will compile warning free on some targets but not
> > on others. This issue should exist on all targets base on the
> > CPU architecture as shown below.
> >
> > #include <stdio.h>
> > #include <inttypes.h>
> >
> > void f( uintptr_t p )
> > {
> >   printf( "Value = %" PRIuPTR "\n", p );
> > }
> >
> > This is a list of warning/no warning for every RTEMS target
> > that compiles on the head.
> >
> > === arm-rtems4.11-gcc - no warning
> > === bfin-rtems4.11-gcc - warning
> > === i386-rtems4.11-gcc - warning
> > === lm32-rtems4.11-gcc - no warning
> > === m68k-rtems4.11-gcc - warning
> > === nios2-rtems4.11-gcc - no warning
> > === or1k-rtems4.11-gcc - warning
> > === powerpc-rtems4.11-gcc - no warning
> > === sh-rtems4.11-gcc - no warning
> > === sparc64-rtems4.11-gcc - no warning
> > === sparc-rtems4.11-gcc - no warning
> > === v850-rtems4.11-gcc - no warning
> >
> > I have tracked this down to newlib's inttypes.h does not detect
> > when gcc defines integer pointer types to long. PRIuPTR turns
> > into "u" not "ul".
> >
> > $ or1k-rtems4.11-gcc -dM -E - </dev/null | grep INTPTR_T
> > #define __INTPTR_TYPE__ long int
> > #define __UINTPTR_TYPE__ long unsigned int
> > $ arm-rtems4.11-gcc -dM -E - </dev/null | grep INTPTR_T
> > #define __INTPTR_TYPE__ int
> > #define __UINTPTR_TYPE__ unsigned int
> >
> > On the above two targets __PTRDIFF_TYPE__ is the same.
> >
> > The code in inttypes.h in question is:
> >
> > #if PTRDIFF_MAX <= __INTTYPES_EXP(INT_MAX)
> > # define __PRIPTR(x) __STRINGIFY(x)
> > # define __SCNPTR(x) __STRINGIFY(x)
> > #elif PTRDIFF_MAX <= __INTTYPES_EXP(LONG_MAX) ||
> > !defined(__have_longlong64)
> > # define __PRIPTR(x) __STRINGIFY(l##x)
> > # define __SCNPTR(x) __STRINGIFY(l##x)
> > #else
> > # define __PRIPTR(x) __STRINGIFY(ll##x)
> > # define __SCNPTR(x) __STRINGIFY(ll##x)
> > #endif
> >
> > Any thoughts on how to detect when it should use
> > "ul" for long uinptr_t instead of "u" for targets with
> > int uintptr_t?
> >
> > I don't see any related variables that differ in the predefined
> > CPP macros except the actual type.
> >
> > Thanks.
> >
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill@OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
> 
> 
>