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: [newlib] print formats for FAST and LEAST types


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

Attachment: pgp6qmqZ4Xopy.pgp
Description: PGP signature


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