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: inttypes.h bug leads to inconsistent warnings cross platform



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


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