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 -Wno-format since we adde
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
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
>> find a way to get compil
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.
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 w
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 warnin
