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