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: printf/inttypes.h warning


Hi

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.

--joel

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

On December 16, 2014 7:44:39 AM PST, Joseph Myers<joseph@codesourcery.com>  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
__INTPTR_TYPE__
looks right to me.  The gcc/config/newlib-stdint.h file seems to be
outdated???
newlib-stdint.h is meant to replicate the logic used by all versions of

newlib to select these types, including versions predating the addition
of
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
GCC
is built) for such purposes as Fortran C bindings.

* newlib stdint.h as of 2008/9 was used as the source of truth about
these
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
change
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.

--joel

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]