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.
Usage of %z outside safe-known seems really limited. It would be sad to
force SIZE_T_MODIFIER for elog calls (where it is prevalent) just for
the benefit of usage outside of elog on fringe platforms -- you're right
that we do have a few cases of %z under fprintf() already. The good
news is that AFAICS those strings are not translatable today, so
changing only those to SIZE_T_MODIFIER (and leaving alone those using
elog) is maybe not such a big deal. I think those are dshash.c, dsa.c,
slab.c and aset.c only.
(I assume without checking that with the stringinfo API it's OK to use %z).
Can't we raise warnings on such usages with an archetype change? (Hm,
is it possible to change archetype for fprintf?)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
