Re: printf format selection vs. reality

I wrote:
> 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".

I pushed that, but while working on the patch I noticed two other
overly-optimistic assumptions of the same kind:

* If the system's printf doesn't support the "z" length modifier,
we assume we can deal with that by using our own snprintf. Just
as in the "ll" case, that only works to the extent that "z" is
used only with elog/ereport, not directly in printf or fprintf.
I've not dug for counterexamples, but it's hard to believe there
aren't some now, and even harder to believe we'd not introduce
them in future.

* If the system's printf doesn't support argument reordering (%$n),
we assume we can deal with that by using our own snprintf. Again,
that's bunk because we apply translation to all sorts of strings
that are given directly to printf or fprintf.

I think that a reasonably painless solution to the second point
is just to reject --enable-nls if printf doesn't support argument
reordering. This would not even break any buildfarm animals,
AFAICT; all the ones that are testing for the feature are finding
it present. And, though the feature seems to postdate C99, it's
hard to believe that anybody who'd care about NLS would be using
a platform that hasn't got it.

The %z issue is a good deal stickier, as (a) we do have a surviving
Unix buildfarm animal (gaur/pademelon) that doesn't support %z,
and (b) so far as I can tell from available documentation, Windows
doesn't support it either, until very recently (like VS2017).
If it were just (a), that would probably mean it's time to put
gaur/pademelon out to pasture, but (b) means we have to deal with
this somehow.

The practical alternatives seem to be to avoid %z in frontend code,
or to invent a macro SIZE_T_MODIFIER and use it like INT64_MODIFIER.
Either one will be extremely error-prone, I'm afraid, unless we can
find a way to get compiler warnings for violations.

Also, I'm suspcious that we're going to have to back-patch something
for this.

Thoughts?

regards, tom lane