This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: long unsigned int vs. uint32_t again
Andy Koppe wrote:
> Chuck wrote:
>> cygwin's <inttypes.h> has:
>> #define PRIu32 "lu"
>>
>> and <stdint.h> has
>> typedef unsigned int uint32_t;
>>
>> Is it possible that our inttypes.h should be changed, to use "u" for 8, 16, and 32 bits?
>
> Yep, I'd say so.
Linux agrees with you. Its inttypes.h has:
# if __WORDSIZE == 64
# define __PRI64_PREFIX "l"
# define __PRIPTR_PREFIX "l"
# else
# define __PRI64_PREFIX "ll"
# define __PRIPTR_PREFIX
# endif
...
# define PRIu8 "u"
# define PRIu16 "u"
# define PRIu32 "u"
# define PRIu64 __PRI64_PREFIX "u"
and similar, throughout [*]. Fortunately, this file is from src/winsup,
not src/newlib, so we don't have to worry about the impact of any change
on other platforms supported by newlib.
Should I prepare a patch (and I assume we're not worried yet about
WORDSIZE==64)?
>> Or is gcc's -Wformat=2 in 3.4.4 just too strict here -- and should be checking
>> the actual bitwidths of types against the formats, before assuming that
>> "lu" doesn't match uint32_t?
>
> No. "long" and "int" are different types, and ignoring this would just
> store up trouble for when code is ported to platforms with 64-bit
> longs.
Ack.
--
Chuck
[*] The *FAST* macros follow a different pattern:
# define PRIuFAST8 "u"
# define PRIuFAST16 __PRIPTR_PREFIX "u"
# define PRIuFAST32 __PRIPTR_PREFIX "u"
# define PRIuFAST64 __PRI64_PREFIX "u"
because stdint.h has this (and similar, throughout):
typedef unsigned char uint_fast8_t;
#if __WORDSIZE == 64
typedef unsigned long int uint_fast16_t;
typedef unsigned long int uint_fast32_t;
typedef unsigned long int uint_fast64_t;
#else
typedef unsigned int uint_fast16_t;
typedef unsigned int uint_fast32_t;
__extension__
typedef unsigned long long int uint_fast64_t;
#endif
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/