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: inttypes.h bug leads to inconsistent warnings cross platform


I was thinking of having something like:

<logic in newlib that figures out what uintptr_t is>

<PRIuPTR logic from newlib>

int printf(char *x, ...);

int main()
{
    uintptr_t p = 0;

    return printf("%" PRIuPTR "\n", p);
}

then compile this with -Wall -Werror in the compilation test so it either
fails or succeeds.  You then know that the PRIxPTR code needs tweaking.

-- Jeff J.

----- Original Message -----
> From: "Joel Sherrill" <joel.sherrill@oarcorp.com>
> To: "Jeff Johnston" <jjohnstn@redhat.com>
> Cc: newlib@sourceware.org, "Joseph Myers" <joseph@codesourcery.com>
> Sent: Wednesday, September 10, 2014 4:57:16 PM
> Subject: Re: inttypes.h bug leads to inconsistent warnings cross platform
> 
> 
> 
> On September 10, 2014 3:53:35 PM CDT, Jeff Johnston <jjohnstn@redhat.com>
> wrote:
> >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.
> 
> I can try to write an autoconf test but I am not sure what it would do.
> 
> I grepped the CPP predefined macros when I was investigating this and I see
> Joseph's approach working in a .h but have trouble seeing it as a probe
> test.
> 
> Suggestions?
> 
> 
> >
> >-- 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
> >> 
> >> 
> >> 
> 
> --joel
> 


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