Re: [patch] Use inttypes macros for size_t format string
- Subject: Re: [patch] Use inttypes macros for size_t format string
- From: Tilo Eckert <tilo.eckert@xxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Wed, 22 Jan 2020 12:25:56 +0100
- To: libssh@xxxxxxxxxx
Am 22.01.2020 um 08:49 schrieb Andreas Schneider:
> On Thursday, 16 January 2020 12:55:07 CET g4-lisz@xxxxxxxxxxxx wrote:
>>>> According to that you need to compile with:
>>>> cmake -DCMAKE_C_FLAGS="-D__USE_MINGW_ANSI_STDIO=1" ..
>>> Alternative seems to be:
>>> -Dsnprintf=__mingw_snprintf -Dvsnprintf=__mingw_vsnprintf ...
>> Yes i was a bit overhasty with this patch...
>> I also found that _POSIX_SOURCE does the trick. This would be a bit more
>> But I realized that the binaries get bigger like that, probably because
>> they link in more of their own implementations. Not sure, if this is a
>> good thing...
>> -Dsnprintf=__mingw_snprintf -Dvsnprintf=__mingw_vsnprintf looks like a
>> good compromise to me. I will also test this.
> Which route should we go? Just set _POSIX_SOURCE?
None of them. If you want libssh to work on Windows when built without
MinGW, %z must not be used at all. The Windows implementation of printf
does not support it. You have to use typecasts to print size_t in a
Defining __USE_MINGW_ANSI_STDIO directly has been deprecated and emits a
warning in newer MinGW versions:
Defining one of _XOPEN_SOURCE, _POSIX_C_SOURCE or _POSIX_SOURCE
(deprecated) implicitly enables __USE_MINGW_ANSI_STDIO. MinGW replaces
the printf and scanf function families with C99 compliant versions if
any of the defines is set, leading to slightly larger binaries. However,
that would only fix it if MinGW is used...
Archive administrator: firstname.lastname@example.org