OK, so at first try this revealed (via new -Wformat warnings) existing code using
CURL_FORMAT_CURL_OFF_T[U] with CRT printf() functions:
https://github.com/curl/curl/actions/runs/10504973605/job/29101585339?pr=14643#step:12:158

/cc @bagder

Clearly the format warning on those mingw compiler versions is not functional for how we do things.

Another approach to try is this:

--- a/include/curl/mprintf.h
+++ b/include/curl/mprintf.h
@@ -36,9 +36,9 @@ extern "C" {
   defined(__IAR_SYSTEMS_ICC__)) &&                                      \
   defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) &&         \
   !defined(CURL_NO_FMT_CHECKS)
-#if defined(__MINGW32__) && !defined(__clang__)
+#if defined(__MINGW32__)
 #define CURL_TEMP_PRINTF(fmt, arg) \
-  __attribute__((format(gnu_printf, fmt, arg)))
+  __attribute__((format(__MINGW_PRINTF_FORMAT, fmt, arg)))
 #else
 #define CURL_TEMP_PRINTF(fmt, arg) \
   __attribute__((format(printf, fmt, arg)))

I'll try it once fixed the stray standard printfs in http/client.

The CURL_FORMAT_ defines are meant to work with any printf(). We typically discourage applications from using the curl provided printf functions.

The CURL_FORMAT_ defines are meant to work with any printf(). We typically discourage applications from using the curl provided printf functions.

Ah OK, got it. It throws out the original idea here, but the format-spec patch might be a way to go that's compatible with it. Basically we need to make sure the formats and format-checker are in sync with each other and with standard printf, while curl printf accepts any format flavour anyway.

Also perhaps introducing curl printf into example was a mistake in the previous PR, and should be reverted. (...along with the fprintf() converstions I'm doing now in this PR.)

The initial idea checks out at this point of the PR. Now turning onto the other solution.

With the clean approach we bump into another problem: curl internally uses the %z format (for size_t* and curl_socket_t), which doesn't fit the __MINGW_PRINTF_FORMAT spec with mingw-w64 v7 (2019-11-10) and earlier:
https://github.com/curl/curl/actions/runs/10506559918/job/29106453350?pr=14643

(This might have been a reason why I didn't go with that after testing it in #12489)

One clean (IMO), but laborous fix is to swap %z with a macro that's set to work for all mingw versions. And adjust CURL_FORMAT_SOCKET_T.

The upside is that this only touches internals, not the public headers.

@bagder: After a series of tests, the only way I see to replace
the build hack in place now, is to swap %zd and %zu within
the source to the newly added CURL_FORMAT_[S]SIZE_T.

This brings the format-check, the format specifiers, and the
source code in sync with each other, regardless of mingw
version. It also gives a tool to handle it with any other compiler
that has issues with C99 format specifiers.

(To selectively disable format checks for old mingw-w64
versions, we'd need to include _mingw.h to the public curl
headers. I wouldn't want to take that risk. This header may
alter the compiler env, and in a public header this is an issue.)

Do you think I should go ahead with this?

As discussed, I replaced all %z format strings with new CURL_FORMAT_[X|S]SIZE_T macros.

Script to verify that format-string replacements were done correctly:

curl -LO https://github.com/curl/curl/pull/14643.diff
grep '^-' 14643.diff > 14643-out.diff
grep '^+' 14643.diff > 14643-in.diff
grep -E -o '%[0-9]*z(x|u|d)' 14643-out.diff > 14643-out-fmt.diff
grep -E -o '%[0-9]*" CURL_FORMAT_(X|S)?SIZE_T' 14643-in.diff > 14643-in-fmt.diff
paste 14643-in-fmt.diff 14643-out-fmt.diff | sort | uniq -c > 14643-match.txt

The 493 changes checked out OK:

 340 %" CURL_FORMAT_SIZE_T	%zu
 141 %" CURL_FORMAT_SSIZE_T	%zd
   7 %" CURL_FORMAT_XSIZE_T	%zx
   5 %04" CURL_FORMAT_XSIZE_T	%04zx

Script to verify if the strings remained the same after this patch:

curl -LO https://github.com/curl/curl/pull/14643.diff
grep -E '^(\+|@)' 14643.diff | grep -E -o '("[^"]+"|^\+\+\+.+|^@@)' | tr $'\n' $'\t' | sed -E -e 's/\"\t\"//g' -e 's/\+\+\+ b/--- a/g'       | tr $'\t' $'\n' > in
grep -E '^(-|@)'  14643.diff | grep -E -o '("[^"]+"|^---.+|^@@)'    | tr $'\n' $'\t' | sed -E -e 's/\"\t\"//g' -e 's/(%[0-9]*)z(x|u|d)/\1/g' | tr $'\t' $'\n' > out
diff -u out in > 14643-strings.diff

They did, except one places where I added missing space (plus code changes outside of strings):

--- out
+++ in
@@ -1,9 +1,7 @@
 --- a/configure.ac
 @@
-"$curl_cv_native_windows$have_mingw"
 --- a/docs/examples/CMakeLists.txt
 @@
-"__USE_MINGW_ANSI_STDIO=1"
 --- a/docs/examples/Makefile.am
 @@
 --- a/docs/examples/ftpgetinfo.c
@@ -85,10 +83,10 @@
 "Included max number of cookies (%) in request!"
 --- a/lib/curl_setup.h
 @@
-"lldllucurl/mprintf.h"
 @@
+"curl/mprintf.h"
 @@
-"zd"
+"xudzxzuzd"
 --- a/lib/cw-out.c
 @@
 "cw_out, wrote % %s bytes -> %"
@@ -485,7 +483,7 @@
 @@
 "WS: decode ending with % frame bytes remaining"
 @@
-"WS: starting new frame with % bytes from last oneremaining to be sent"
+"WS: starting new frame with % bytes from last one remaining to be sent"
 @@
 "WS, using chunk size %"
 @@
@@ -531,7 +529,6 @@
 "Bad variable name length (%), skipping"
 --- a/tests/http/clients/CMakeLists.txt
 @@
-"__USE_MINGW_ANSI_STDIO=1"
 --- a/tests/http/clients/Makefile.am
 @@
 --- a/tests/libtest/lib1156.c

As discussed, I replaced all %z format strings with new CURL_FORMAT_[X|S]SIZE_T macros.

Might I ask where this is discussed? Because I fail to see the pros of this change vs the cons. This seem like a step backward for code legibility. A workaround for an older runtime over the whole code base, while there already is a less impactful workaround in place.

Format masks/checks are a long time issue (and not a fun one at that). Despite spending quite a bit of time finding a workaround for making it work everywhere on all platforms (in particular all mingw-w64 versions), I have found none that doesn't have other downsides (like including _mingw.h in a public curl header).

This and referenced PRs (and #14703 made after this PR) have/had plenty of tries in sub commits with just as much dead-ends.

edit: The current solution is build hacks for examples and tests/http/clients. That however doesn't solve this problem for anyone trying to use the public headers in the problematic envs.

The root issue is using C99 format strings in a C89 project.

Certainly the clean solution here is "annoying" (just like the existing solution for 64-bit formats).

If you know a better one that makes pass all cases and still offers format checks, I guess everyone would be happy to use it as a better alternative.

The root issue is using C99 format strings in a C89 project.

I would perhaps go a little further and say:

The root issue is using C99 format strings in a C89 project - and asking the compiler to verify the printf formatting.

We could also just switch off the printf checking and save ourselves from a lot of trouble...

Ultimately the problem is using C99 format strings in a C89 project.

Is this the problem though? If the C99 format is parsed by C89 code this seems perfectly fine to me...

and asking the compiler to verify the printf formatting.

This indeed seems more like the problem, to verify with compilers that are incompatible with the format strings used.

We could also just switch off the printf checking and save ourselves from a lot of trouble...

I would agree this would be a far better choice (for incompatible compilers) than to decrease the code legibility all over the place.

@vszakats we could probably switch if off for all mingw compilers without that being too complicated

Switching it off for all mingw is not complicated, but in that case we'll lose checks for that platform completely.

It basically means that formats will no longer be checked on Windows at all, and also that Windows-specific strings (or Windows-specific uses of strings) will no longer be checked at all. Returning to pre-PR #12489 where these fallouts were fixed after adding format checks for the first time for these.

I don't think that's a useful way to go.

Ultimately the problem is using C99 format strings in a C89 project.

Is this the problem though? If the C99 format is parsed by C89 code this seems perfectly fine to me...

C99 format is or isn't parsed perfectly depending on Windows compiler vendor, compiler version, CRT, format check configuration. Windows is a weird place.

It basically means that formats will no longer be checked on Windows at all

Right, but that's not a terribly big deal IMHO. We have not checked the format for long (meaning that we can survive pretty well without them) and most flags can still be checked fine on other platforms.

I don't think that's a useful way to go.

I'm beginning to think it is. Right now that seems like a lower price than this format change.

C99 format is or isn't parsed perfectly depending on Windows compiler vendor, compiler version, CRT, format check configuration. Windows is a weird place.

The C99 format is parsed in curl by the code in mprintf.c, right? Then it does not depend at all on those things.

It basically means that formats will no longer be checked on Windows at all, and also that Windows-specific strings (or Windows-specific uses of strings) will no longer be checked at all.

Does mingw-w64 >= v8.0.0 have a compatible format checker? Maybe it can be kept on with those versions without having to do a format change.

C99 format is or isn't parsed perfectly depending on Windows compiler vendor, compiler version, CRT, format check configuration. Windows is a weird place.

The C99 format is parsed in curl by the code in mprintf.c, right? Then it does not depend at all on those things.

Correct, the actual parsing doesn't depend on it. However the compiler's checker can only check for the standard it can understand. It doesn't know it's curl's printf, which understands everything.

It basically means that formats will no longer be checked on Windows at all, and also that Windows-specific strings (or Windows-specific uses of strings) will no longer be checked at all.

Does mingw-w64 >= v8.0.0 have a compatible format checker? Maybe it can be kept on with those versions without having to do a format change.

This is what I tried first in this PR. It works. But to check for the mingw-w64 version, curl's public header must include mingw-w64's internal header _mingw.h which sets its version macro. Pulling that in implicitly to all code using libcurl seems ...risky. _mingw.h has side effects like setting a default Windows target version. That's actually the reason why we include it to curl's own code. For other code it might be undesired.

(Notice that mingw-w64 GCC might not be the sole target affected by issues around this. mingw-w64 just happens to be the first "problematic" target where we (I) enabled format checks. We haven't tried with the more popular MSVC.)

I gave #14703 another go and managed to make it work (though CI haven't fully finished yet).

The idea is to override the format check in public curl/mprintf.h with curl internal ones while compiling curl itself.

This makes it possible to sync public format checks with public format strings in curl/system.h.
Which fixes format checks for 3rd-party code using libcurl. Also examples and tests/http/clients, allowing to drop build-level hacks.

Internal format checks continue to use GNU-style, which supports %z with all mingw-w64 versions.

The downside is that this is still a compiler-specific hack (albeit the best looking one so far). It relies on the mingw-w64 feature that allows controlling format check style, adapting to C99 code internally, while sticking to whatever the compiler default is externally.

As for this PR, I agree these format macros are long and not pleasing to type or read (true for existing 64-bit ones too).
@icing already added nicer aliases for the latter: CURL_PRId64 / CURL_PRIu64. I wonder if reception would be more positive if using a friendlier name for size_t, such as CURL_zd / CURL_zu? Food for thought in case we ever want to go full portable.

Closing this one in favour of #14703.