inttypes.h bug leads to inconsistent warnings cross platform

inttypes.h bug leads to inconsistent warnings cross platform

[Joel Sherrill]

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

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

[Sebastian Huber]

On 05/09/14 16:37, Joel Sherrill wrote:
> 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 think there are only two options,

1. add a cascade of #ifdef arch for all special cases, or

2. add builtin defines to GCC.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

[Joel Sherrill]

On September 8, 2014 1:13:59 AM CDT, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:
>On 05/09/14 16:37, Joel Sherrill wrote:
>> 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 think there are only two options, loop
>
>1. add a cascade of #ifdef arch for all special cases, or
>
>2. add builtin defines to GCC.

This is the conclusion I came to. 

I am not sure which is less painful. My gut says it would have to be added to a lot more places in gcc than newlib. It is easy to solve in newlib. Although it seems more correct to add it to GCC.

I suppose I should restart this thread over at GCC to get more opinions.

I am traveling this week. I reverted the warning fix patch locally if you want too revert it in the RTEMS tree.

--joel

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

[Sebastian Huber]

On 08/09/14 10:12, Joel Sherrill wrote:
>
> On September 8, 2014 1:13:59 AM CDT, Sebastian Huber<sebastian.huber@embedded-brains.de>  wrote:
>> >On 05/09/14 16:37, Joel Sherrill wrote:
>>> >>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 think there are only two options, loop
>> >
>> >1. add a cascade of #ifdef arch for all special cases, or
>> >
>> >2. add builtin defines to GCC.
> This is the conclusion I came to.
>
> I am not sure which is less painful. My gut says it would have to be added to a lot more places in gcc than newlib. It is easy to solve in newlib. Although it seems more correct to add it to GCC.
>
> I suppose I should restart this thread over at GCC to get more opinions.

I think the GCC support is incomplete since it offers builtin defines for the 
limits and the constants (e.g. #define __INT32_C(c) c ## L).

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

[Joel Sherrill]

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

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

[Joseph S. Myers]

On Wed, 10 Sep 2014, Joel Sherrill wrote:

> Adding Joseph Myers since newlib-stdint.h appears to have
> originated with him.

Well - newlib-stdint.h was designed to replicate the logic that already 
existed in newlib to define these types, which defined intptr_t to be the 
same as ptrdiff_t, and uintptr_t to be the corresponding unsigned type 
(normally the same as size_t).

> 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?

GCC's predefines are intended for stdint.h, not for inttypes.h given 
that's not required for freestanding implementations so GCC doesn't try to 
provide it.

You could have a header varying depending on the architecture (or with 
architecture conditionals) that embeds the logic about the choice of types 
here.  Or you could do some sort of hack along the lines of

#define signed +0
#define int +0
#define long +1
#if __INTPTR_TYPE__ == 2
/* long long */
#elif __INTPTR_TYPE__ == 1
/* long */
#elif __INTPTR_TYPE__ == 0
/* int */
#else
#error
#endif
#undef signed
#undef int
#undef long

to identify what type is being used (it's invalid to include a standard 
header with any keywords defined as macros, so it's valid for such a 
header to temporarily define such macros then undefine them).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joel Sherrill]

On September 10, 2014 3:25:14 PM CDT, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
>On Wed, 10 Sep 2014, Joel Sherrill wrote:
>
>> Adding Joseph Myers since newlib-stdint.h appears to have
>> originated with him.
>
>Well - newlib-stdint.h was designed to replicate the logic that already
>
>existed in newlib to define these types, which defined intptr_t to be
>the 
>same as ptrdiff_t, and uintptr_t to be the corresponding unsigned type 
>(normally the same as size_t).
>
>> 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?
>
>GCC's predefines are intended for stdint.h, not for inttypes.h given 
>that's not required for freestanding implementations so GCC doesn't try
>to 
>provide it.

OK. This is from POSIX and I was just looking for a reliable way to determine the information required.

>You could have a header varying depending on the architecture (or with 
>architecture conditionals) that embeds the logic about the choice of
>types 
>here.  

That was mentioned but it seemed like something else to maintain and likely no one would update it unless it errored off on an unknown architecture. A new port could ignore fixing it very easily.

> Or you could do some sort of hack along the lines of
>
>#define signed +0
>#define int +0
>#define long +1
>#if __INTPTR_TYPE__ == 2
>/* long long */
>#elif __INTPTR_TYPE__ == 1
>/* long */
>#elif __INTPTR_TYPE__ == 0
>/* int */
>#else
>#error
>#endif
>#undef signed
>#undef int
>#undef long
>
>to identify what type is being used (it's invalid to include a standard
>
>header with any keywords defined as macros, so it's valid for such a 
>header to temporarily define such macros then undefine them).

That is very clever!!!

If this works, is anyone opposed to me submitting a patch with this?


--joel

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

[Jeff Johnston]

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
> 
> 
> 

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

[Joel Sherrill]

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

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

[Jeff Johnston]

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
> 

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On 09/10/2014 03:13 PM, Jeff Johnston wrote:
> 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.

That's fragile (depends on -Werror working), whereas you can do type
detection on ALL compliant C compilers via function pointer assignment
or function redeclaration.  Lightly tested, but observe how I can
quickly probe that uintptr_t is equal to unsigned long on my x86_64
GNU/Linux box, with no need for warning detection:

$ cat foo.c
#include <inttypes.h>
extern int foo(uintptr_t);
extern int foo(PROBE);
int main() { return 0; }
$ gcc -o foo foo.c -D PROBE='unsigned long'
$ gcc -o foo foo.c -D PROBE='unsigned long long'
foo.c:3:12: error: conflicting types for ‘foo’
 extern int foo(PROBE);
            ^
foo.c:2:12: note: previous declaration of ‘foo’ was here
 extern int foo(uintptr_t);
            ^
$

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

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

[Jeff Johnston]

----- Original Message -----
> From: "Eric Blake" <eblake@redhat.com>
> To: "Jeff Johnston" <jjohnstn@redhat.com>, "Joel Sherrill" <joel.sherrill@oarcorp.com>
> Cc: newlib@sourceware.org, "Joseph Myers" <joseph@codesourcery.com>
> Sent: Wednesday, September 10, 2014 11:39:44 PM
> Subject: Re: inttypes.h bug leads to inconsistent warnings cross platform
> 
> On 09/10/2014 03:13 PM, Jeff Johnston wrote:
> > 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.
> 
> That's fragile (depends on -Werror working), whereas you can do type
> detection on ALL compliant C compilers via function pointer assignment
> or function redeclaration.  Lightly tested, but observe how I can
> quickly probe that uintptr_t is equal to unsigned long on my x86_64
> GNU/Linux box, with no need for warning detection:
> 
> $ cat foo.c
> #include <inttypes.h>
> extern int foo(uintptr_t);
> extern int foo(PROBE);
> int main() { return 0; }
> $ gcc -o foo foo.c -D PROBE='unsigned long'
> $ gcc -o foo foo.c -D PROBE='unsigned long long'
> foo.c:3:12: error: conflicting types for ‘foo’
>  extern int foo(PROBE);
>             ^
> foo.c:2:12: note: previous declaration of ‘foo’ was here
>  extern int foo(uintptr_t);
>             ^
> $
> 

Yes, that would be a better strategy for the test.


> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
>