On 23.01.20 11:22, Tilo Eckert wrote: > Am 23.01.2020 um 10:00 schrieb Andreas Schneider: >> On Wednesday, 22 January 2020 17:40:04 CET Tilo Eckert wrote: >>> Am 22.01.2020 um 13:56 schrieb g4-l...@tonarchiv.ch: >>>> For Windows I can find documentation of "z" as supported spezifier: >>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specificatio >>>> n-syntax-printf-and-wprintf-functions?view=vs-2019#size-prefixes-for-print >>>> f-and-wprintf-format-type-specifiers >>>> >>>> But not sure since when this is supported. >>> Apparently, %zu is supported since VS 2015 (or 2013?), %Iu is the older >>> MS-specific alternative. Support for ANSI C99 still seems not to be 100% >>> complete in VS. >>> >>>> But anway: What is the advantage of using typecasts instead of a format >>>> spezifier macro (see my patch)? You still have to use OS specific type >>>> casts. Or I'm understanding this wrong? >>> There is no printf format specifier macro for size_t in standard >>> headers. The PRIdS macro in priv.h defines a format specifier for >>> printing a ssize_t. We would need a PRIuS macro (`Iu` on Windows, `zu` >>> everywhere else) as you suggested in an earlier email because size_t is >>> unsigned. However, I'm not 100% certain whether this works in all build >>> environments. If you get this macro wrong, not all compilers will warn >>> you about a bad format string. >>> >>> A safe, headache-free, C89 compatible, but not as pretty alternative >>> that will not break in compiler environments of the last 20+ years: >>> printf("%llu", (long long unsigned) size) >> I would prefer to go with: >> >> -Dsnprintf=__mingw_snprintf -Dvsnprintf=__mingw_vsnprintf >> >> >> The question is if we should document how to do it with mingw and suggest a >> toolchain file having this set, or if we add this to our cmake or priv.h in >> case of MinGW ... > This is not a MinGW problem, but a general Windows one as I already > tried to explain. Format specifier %zu is not supported in VS versions > older than 5 years because MS didn't bother to make their printf > implementation comply to C99 for a long time. Hence, we should use > MS-proprietary %Iu on Windows or avoid using %z at all to make format > strings compatible with MinGW and VS.
After all I vote for my own patch (see mail "[patch ] (Now complete) Use inttypes macros for size_t format string") because this is the smallest change of already released code. Both `z` and inttypes macros are in the lib's sources already. If still one build environment gets it wrong, we only need some more adaption in priv.h and no changes in other code. Regards, Till