(perhaps) strange bug in our printf function!? #1290

<pre>printf("CBlock::WriteToDisk() : Truncated block file %s (new size: %u bytes)\n", std::string.c_str(), uint64 &);</pre>

Result: "CBlock::WriteToDisk() : Preallocated C:\Bitcoin\testnet\blk0001.dat bytes for block file 2130706432" -> good

<pre>printf("CBlock::WriteToDisk() : Truncated block file %u (new size: %s bytes)\n", uint64 &, std::string.c_str());</pre>

Result: "CBlock::WriteToDisk() : Preallocated 2130706432 bytes for block file (null)" -> bad

I can't explain, but the uint64 before the reference to a std::string works, reverse order and the std::string displays as (null). Can a dev try to reproduce this or has an idea? This is an occurence in an own-build, so perhaps not a global problem!

Is %u the right format character for an int64? I don't think so -- we have these:

util.h:

#if defined(_MSC_VER) || defined(__MSVCRT__)
#define PRI64d  "I64d"
#define PRI64u  "I64u"
#define PRI64x  "I64x"
#else
#define PRI64d  "lld"
#define PRI64u  "llu"
#define PRI64x  "llx"
#endif

%u is unsigned integer, usually 32 bits. uint64 obviously is 64. So you push a 64-bit value on the stack,, but %u only consumes the first 32 bits of it (which, if the the number is less than 2^32, is the right value). It leaves the higher part to be interpreted as a string pointer, though.

I knew it's a 64 bit value, what I didn't know was that we have a %"PRI64u" define. So %llu should be fine. Will try and report back, thanks!

@sipa is right, what you see is consistent with little-endian. This is, BTW, why people concerned with type-safety hate printf. Some compilers will warn you for these mistakes with -Wformat.

Great, now it works and thanks for that quick help -> closed!

No, %llu is not fine. uint64_t is not guaranteed to be the same as unsigned long long. Just use PRI64u.

@sipa: That's what I did, thanks again.