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/
