On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>>> On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
>>>> I think this approach is fundamentally broken, because it can't reasonably
>>>> cope with any case more complicated than "%zu" or "%zd".
>
>>> Am I just too tired, or am I not getting how INT64_FORMAT currently
>>> allows the arguments to be used posititional?
>
>> It doesn't, which is one of the reasons for not allowing it in
>> translatable strings (the other being lack of standardization of the
>> strings that would be subject to translation).
>
> On second thought, that answer was too glib. There's no need for %n$
> in the format strings *in the source code*, so INT64_FORMAT isn't getting
> in the way from that perspective. However, expand_fmt_string() is
> necessarily applied to formats *after* they've been through gettext(),
> so it has to expect that it might see %n$ in the now-translated strings.
>
> It's still the case that we need a policy against INT64_FORMAT in
> translatable strings, though, because what's passed to the gettext
> mechanism has to be a fixed string not something with platform
> dependencies in it. Or so I would assume, anyway.
Well, that's kinda problematic, isn't it? Printing the variable into
a static buffer so that it can then be formatted with %s is pretty
pessimal for a message that we might not even be planning to emit.
Perhaps we should jettison entirely the idea of using the operating
system's built-in sprintf and use one of our own that has all of the
nice widgets we need, like a format code that's guaranteed to be right
for uint64 and one that's guaranteed to be right for Size. This could
turn out to be a bad idea if the best sprintf we can write is much
slower than the native sprintf on any common platforms ... and maybe
it wouldn't play nice with GCC's desire to check format strings. But
what we're doing now is a real nuisance, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
