This is the mail archive of the 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: printf/inttypes.h warning


Top posting because I now have results from testing making
the proposed change to gcc's newlib-stdint.h to use the
same logic as newlib-glibc.h

All the targets that built are now warning free.  At the moment,
avr, m32c, and nios2 won't build.

The gcc patch is attached. I thought we should discuss it here
before posting it to gcc.

Besides, I can't get to gcc's bugzilla this morning for some reason.


On 12/16/2014 09:53 AM, Joel Sherrill wrote:

On December 16, 2014 7:44:39 AM PST, Joseph Myers<>  wrote:
On Tue, 16 Dec 2014, Corinna Vinschen wrote:

It is GCC. gcc/config/newlib-stdint.h where GCC defines the types.
Ok, I didn't know there's newlib-specific stuff in GCC.  I'm just
not sure in how far this is newlib's fault.  The usage of
looks right to me.  The gcc/config/newlib-stdint.h file seems to be
newlib-stdint.h is meant to replicate the logic used by all versions of

newlib to select these types, including versions predating the addition
macros such as __INTPTR_TYPE__.

* The choices of these types are meant to be constant over time.

* GCC needs to know them (without reference to the newlib headers when
is built) for such purposes as Fortran C bindings.

* newlib stdint.h as of 2008/9 was used as the source of truth about
types when writing newlib-stdint.h.

* When newlib uses macros such as __INTPTR_TYPE__ it's indirectly using

GCC's newlib-stdint.h as a source of truth - but this should never
the choice of types relative to what would be used with older GCC or
non-GCC compilers.
I.don't disagree with any of that but I wouldn't necessarily treat the old newlib stdint.h as 100% correct.  I don't believe that most embedded targets ever gave much thought to this issue and it is propagating into inttypes.h. Other than cygwin, I doubt binary comparability is even an issue as most build from source..

For sure this uses different logic than glic-stdint.h and that results in some targets using int for pointer types while others use long.

We can make it consistent in newlib-stdint.h or we have to add target architecture specific conditional logic inttypes.h to make the printf PRIxxx match the type.

It is inconsistent now and has to be fixed on one side or the other.

I always lean to simple and consistent which makes me want to fix newlib-stdint.h.


Attachment: 0001-newlib-stdint.h-Use-glibc-s-logic-for-uintptr_t-and-.patch
Description: Text document

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