Re: BUG #15511: Drop table error "invalid argument"

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> (4) However, that leaves us with a translation problem, because msgfmt
>> doesn't detect some things that we'll fail on at runtime. What shall
>> we do about that?

> A shorter path, though one with less additional benefits, would
> presumably be to find a way to make msgfmt fail on things that we'll
> fail on..? Or otherwise detect such cases..?

What I did to locate the broken translation in the first place was
to make a heavily lobotomized version of snprintf.c which would detect
EINVAL problems in a supplied format string, without trying to actually
fetch any values or emit any output. Then I applied it to every string
in tr.po. This was a complete kluge only suitable for one-shot use,
but you could imagine making something a bit more production-ready
and then inserting it into the translation pipeline somewhere. It'd
likely be worth applying it to the original strings as well as the
translated ones, in case we have any seldom-executed code in which
the original string is bad itself.

I noted while looking at the problem that it's somewhat accidental
that snprintf.c reports EINVAL rather than just producing bogus
output for this case. If we were planning to go this direction,
I'd be inclined to make it report EINVAL for any situation where
it hits an unrecognized format code --- ie put an error into the
default cases in the switches there.

That's just handwaving though, as I have little idea what the
"translation pipeline" looks like.

regards, tom lane