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] |
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] |