This is the mail archive of the
mailing list for the newlib project.
Re: inttypes.h bug leads to inconsistent warnings cross platform
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 10 Sep 2014 15:46:53 -0500
- Subject: Re: inttypes.h bug leads to inconsistent warnings cross platform
- Authentication-results: sourceware.org; auth=none
- References: <5409CAAD dot 1030801 at oarcorp dot com> <5410A1D3 dot 4070106 at oarcorp dot com> <Pine dot LNX dot 4 dot 64 dot 1409102016420 dot 21930 at digraph dot polyomino dot org dot uk>
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?