Tue Dec 16 15:54:00 GMT 2014
On December 16, 2014 7:44:39 AM PST, Joseph Myers <firstname.lastname@example.org> 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
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.
More information about the Newlib