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

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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