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
