Re: printf format selection vs. reality

On Thu, May 24, 2018 at 8:28 AM, Tom Lane wrote: > The problem is to get a compiler that thinks that %z is a violation > of *any* archetype. gaur's compiler does think that, but it has no > archetype that does accept %z, so that's little help (I've had it > building with

Re: printf format selection vs. reality

Sigh, I'm an idiot. I forgot that USE_REPL_SNPRINTF doesn't just replace snprintf, it replaces the entire *printf family; see port.h lines 137ff. So actually we're OK as far as these %z and argument-reordering concerns go. Maybe the comments in configure could use a bit of work though. There's

Re: printf format selection vs. reality

Alvaro Herrera writes: > On 2018-May-23, Tom Lane wrote: >> 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

Re: printf format selection vs. reality

On 2018-May-23, Tom Lane wrote: > 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.

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

printf format selection vs. reality

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