This is the mail archive of the
mailing list for the newlib project.
Re: inttypes.h bug leads to inconsistent warnings cross platform
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: "newlib at sourceware dot org" <newlib at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Wed, 10 Sep 2014 14:09:07 -0500
- Subject: Re: inttypes.h bug leads to inconsistent warnings cross platform
- Authentication-results: sourceware.org; auth=none
- References: <5409CAAD dot 1030801 at oarcorp dot com>
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?
On 9/5/2014 9:37 AM, Joel Sherrill wrote:
> 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)
> # define __PRIPTR(x) __STRINGIFY(ll##x)
> # define __SCNPTR(x) __STRINGIFY(ll##x)
> 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.
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