massive compiler warning spam after #2767 #3236

I'm currently using gcc version 4.8.1 (rev5, Built by MinGW-W64 project) to build Bitcoin-Qt and after #2767 was merged I get spammed by misc compiler warnings.

https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L408

<pre> C:\Users\Diapolo\bitcoin.Qt\src\net.h: Warnung:unknown conversion type character 'l' in format [-Wformat=] LogPrint("net", "askfor %s %"PRId64" (%s)\n", inv.ToString().c_str(), nRequestTime, DateTimeStrFormat("%H:%M:%S", nRequestTime/1000000).c_str()); ^ C:\Users\Diapolo\bitcoin.Qt\src\net.h: Warnung:format '%s' expects argument of type 'char*', but argument 4 has type 'int64_t {aka long long int}' [-Wformat=] C:\Users\Diapolo\bitcoin.Qt\src\net.h: Warnung:too many arguments for format [-Wformat-extra-args] </pre>

https://github.com/bitcoin/bitcoin/blob/master/src/util.h#L166

<pre> C:\Users\Diapolo\bitcoin.Qt\src\util.h: Warnung:unknown conversion type character 'l' in format [-Wformat=] #define strprintf(format, ...) real_strprintf(format, 0, __VA_ARGS__) ^ C:\Users\Diapolo\bitcoin.Qt\src\util.h: Warnung:too many arguments for format [-Wformat-extra-args] #define strprintf(format, ...) real_strprintf(format, 0, __VA_ARGS__) ^ </pre>

caused by: https://github.com/bitcoin/bitcoin/blob/master/src/util.h#L232

There are more, I'll update as necessary...

@sipa These here... sorry got kicked from IRC ^^.

It looks like the pull made the PRId64 macros invalid for windows? The format characters for long long/size_t are different between windows and linux (blame microsoft). PRId64 and such are meant to abstract that difference away.

Re-adding this in util.h fixes it for me:

<pre> #ifdef PRId64 #if defined(_MSC_VER) || defined(__MSVCRT__) #undef PRId64 #define PRId64 "I64d" #undef PRIu64 #define PRIu64 "I64u" #undef PRIx64 #define PRIx64 "I64x" #endif #endif </pre>

Seems there is something not working very good in MinGWs inttypes.h then :-/ or we are not setting up for MinGW correctly!?

Seems that way, let's add it back to prevent breakage.

I don't think you should have the outer #ifdef PRId64 though; stated this way it only defines the PRId64/PRIu64/PRIx64 if it's already defined, whereas it should always define them.

If #2767 made those macro's invalid, that's not Microsoft's fault, but MinGW's, as they come from inttypes.h now.

@sipa Blame Microsoft for using different format strings in the first place instead of simply the C99 format characters, in which case we wouldn't need the macros at all.

It's even worse: MSVC doesn't define those macros, and IIRC it doesn't have inttypes.h either as that's C99 and they still refuse to support that in their shitty compiler.

Though agreed in this specific case it's a bug in MinGW, as they provide the wrong values for the macros. @diapolo If you can confirm that inttypes.h comes with MinGW can you also file this bug upstream? It appears their bug tracker is http://sourceforge.net/p/mingw-w64/bugs/

@laanwj Done, see https://sourceforge.net/p/mingw-w64/bugs/360/

@laanwj Can you please take a look at the posted answer from Jonathan Yong in the above bug report.

I verified back with the old mingw with a test case that the C99 characters do not work with the strprintf that we currently use (which uses _vsnprintf on WIN32).

So the warning is not a red herring in the current state.

I've looked somewhat deeper and there is a define called __USE_MINGW_ANSI_STDIO that makes vsnprintf (making use of __mingw_*printf) behave exactly like C99. Maybe that's what he means?

See http://sourceforge.net/apps/trac/mingw-w64/wiki/printf%20and%20scanf%20family

I don't think we should switch to those, though. We do not require C99 at this point, we shouldn't as we're writing C++. Even C++11 does not require C99 extensions.

In the longer run best would be to get rid of the dependency on the system's XXXprintf completely, as seemingly it's not a stable cross-platform interface and not C++ idiom either.

Further discussion happens in #3237