From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: printf format selection vs. reality
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13102.1526749980.1@sss.pgh.pa.us>
Date: Sat, 19 May 2018 13:13:00 -0400
Message-ID: <13103.1526749980@sss.pgh.pa.us>
Precedence: bulk

Our configure script goes to considerable lengths to try to identify
what printf width modifier to use for int64 values.  In particular
see PGAC_FUNC_SNPRINTF_LONG_LONG_INT_MODIFIER, which claims

# MinGW uses '%I64d', though gcc throws a warning with -Wall,
# while '%lld' doesn't generate a warning, but doesn't work.

However, if we decide that we ought to use our own snprintf replacement,
we throw that info away and set INT64_FORMAT to "%lld" which we know
is what that code uses.

This was all right when that code was first written, when we had only
a very small number of uses of INT64_FORMAT and they all were in
snprintf() calls.  It's been a long time since that was true: pgbench,
in particular, has been passing INT64_FORMAT to the native printf
with increasing enthusiasm.  In reality, we do not anymore work with
situations where our snprintf has a different idea about this format
modifier than libc does.

What's more, as far as I can find, we do not have any buildfarm members
that set INT64_MODIFIER to anything other than "l" or "ll", which no
doubt explains why we've not noticed a problem.  The comment quoted
above doesn't seem to apply to any current buildfarm members.

I think we should abandon the pretense that we can work with libc
printfs that accept anything but "l"/"ll", and rip out the excess
complexity in configure, just setting INT64_MODIFIER to "l" or "ll"
depending on whether "int64" is "long" or "long long".

Comments?

			regards, tom lane