Re: Add %z support to elog/ereport?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

Well, it's a tad annoying, but a quick grep says there are maybe 40
cases of this in our source code, so I'm not sure it's rising to the
level of a must-fix problem.

> 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.

That last is a deal-breaker. It's not just whether "gcc desires" to check
this --- we *need* that checking, because people get it wrong without it.

I thought about proposing that we insist that snprintf support the "ll"
flag (substituting our own if not). But that doesn't really fix anything
unless we're willing to explicitly cast the corresponding values to
"long long", which is probably not workable from a portability standpoint.
I'm not really worried about platforms thinking long long is 128 bits ---
I'm worried about old compilers that don't have such a datatype.

regards, tom lane