Silence inttypes.h compiler warnings on Windows #3237

• the warnings are related to MinGWs inttypes.h (observed with MinGW based on GCC version 4.8.1 (rev5, Built by MinGW-W64 project) and likely other version also suffer from this)
• fixes #3236

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/387f2c5e7a14f7d8773dda0d72d85f5563c7347d for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

Please verify that it continues to build and work as expected with the Precise 12.04-based win32 gitian which has mingw based on gcc-4.6.x.

@diapolo If I understand this correctly you're giving yourself too little credit. This does not only silence warnings, but it fixes printf format strings throughout the source code for Windows builds.

ACK in any case

Maybe we should add some sprintf tests to catch problems with this in the pulltester.

@diapolo Can you try removing the inttypes.h include completely on WIN32? I think it's only used for PRId64 (and friends) at this point and we shouldn't use C99 headers on WIN32.

I'll check this out tomorrow... thanks for helping out.

@Diapolo this only coincidentally fixes most instances of the warning because util.h is depended on by almost every file (indirectly at least). The inttypes.h include is spread across all of the files that use PRI[xdu]64 directly.

I would rather spend some time getting rid of all of the *printf functions and replace them with [i,o][,f,string]streams where appropriate. Once that is done, there will be no dependence on inttypes.h anywhere.

It is quite urgent to fix this because it breaks strprintf on Windows XP and earlier (see http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf) @brandondahler have you checked how much strprintf is used? There's at least 130 direct usages. Converting that all to iostreams would be a massive endavour. Had I realized that inttypes.h was C99 I would not have ACKed your refactor :/ `

So unless we revert all those changes it forces us into the C99 route for the short term even on Windows. Thus to define __USE_MINGW_ANSI_STDIO and use the mingw C99 equivalent functions. I'd rather not have because this burns all the bridges to MSVC support, but no one cared about that anyway so it's not much of a loss.

In the longer term boost::format is a typesafe printf-backward-compatible function that natively uses std::strings, so I think that would be the way to go to replace strprintf. The syntax is different though (http://www.boost.org/doc/libs/1_55_0/libs/format/doc/format.html) so this still implies quite a lot of work.

Continued in #3244