[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] Use inttypes macros for size_t format string


On Wednesday, 22 January 2020 17:40:04 CET Tilo Eckert wrote:
> Am 22.01.2020 um 13:56 schrieb g4-lisz@xxxxxxxxxxxx:
> > 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 ...


	Andreas



Follow-Ups:
Re: [patch] Use inttypes macros for size_t format stringTilo Eckert <tilo.eckert@xxxxxxx>
Archive administrator: postmaster@lists.cynapses.org