[newlib] print formats for FAST and LEAST types
Corinna Vinschen
vinschen@redhat.com
Tue Jul 21 12:37:00 GMT 2015
On Jul 15 15:02, Andre Vieira wrote:
> On 14/07/15 15:57, Corinna Vinschen wrote:
> > [...]
> > #undef signed
> > #undef int
> > #undef long
> > #define signed +0
> > #define int +0
> > #define long +1
> > [...]
> > #if __INT32_TYPE__ == 1
> > #define _INT32_EQ_LONG
> > #elif __INT32_TYPE__ == 0
> > /* Nothing to define because int32_t is safe to print as an int. */
> > #else
> > #error "Unable to determine type definition of int32_t"
> > #endif
> > #undef long
> > #undef int
> > #undef signed
> > [...]
> >
> >__INT32_TYPE__ is defined by GCC as well. If __INT_FAST32_TYPE__ is
> >int, then why is __INT32_TYPE__ long? And if that's the right thing to
> >do, we need a patch to sys/_intsup.h to apply the same check to
> >__INT_FAST32_TYPE__ and use that to define __PRI32fast and __SCN32fast
> >macros.
> >
> >
> >Corinna
> >
> Hi Corinna,
>
> Thank you for your quick replies!
>
> I don’t know whether the current behavior of assigning INT32_TYPE and
> INT_FAST32_TYPE the types "long" and "int" respectively given INT_TYPE_SIZE
> = LONG_TYPE_SIZE = 32, is the right thing to do. Might be worth bringing it
> up with someone, maybe the gcc mailing list?
Yes. Using different base types for types of the same size sounds
fishy to me.
> However, as is, _intsup.h and inttypes.h don’t reflect these discrepancies
> and we could use the same approach as was used with _INT32_EQ_LONG to mend
> that.
Not sure on that specific account, but in theory, yes, as I outlined
above.
> Also Kevin brought to our attention that inttypes.h is riddled with the
> assumption that intNN_t == int_fastNN_t == int_leastNN_t.
Yes, that could be rectified by defining matching __PRI<X>fast,
__SCN<X>least macros.
>
> For instance, on my system SCNdFAST8 will yield 'hhd' whereas INT_FAST8_TYPE
> is 'int'. All other PRIdFAST8, PRId8 and PRIdLEAST8 will be 'd'. Not
> entirely sure this is expected behaviour or not. What is your opinion on
> this?
> Might be also good to point out that printf only seems to warn against using
> formats that may represent larger integers than the ones passed as
> arguments.
Please feel free to send patches.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150721/bdd0a9e6/attachment.sig>
More information about the Newlib
mailing list