inttypes.h bug leads to inconsistent warnings cross platform
Wed Sep 10 20:47:00 GMT 2014
On September 10, 2014 3:25:14 PM CDT, "Joseph S. Myers" <email@example.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
>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
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
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 */
>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?
More information about the Newlib