Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Dec-06, Tom Lane wrote:
>> In principle, we could write some Perl code that exactly matches what
>> snprintf.c thinks is valid input, but I think that keeping it in sync
>> would be a nightmare. The concept I had in mind was to make a variant
>> version of snprintf.c that just validates a format string, and can be
>> compared to snprintf.c by diff'ing. (Or, perhaps, sprinkle snprintf.c
>> with #ifdefs so that compiling it with the right -D flag produces what
>> we want; though that might look too ugly.) If you don't mind adding
>> a C compiler to the list of dependencies for pg-make-po, we could imagine
>> having it compile up such a program at startup and then apply it to
>> each catalog.
> I don't follow. Why don't we just compile snprintf.c as-is and another
> .c file with a function that invokes vsnprintf on each translated string
> on a .po file and prints an error if vsnprintf returns EINVAL?
Because figuring out what additional arguments go with a particular
format string is pretty hard, and we can't just not do that, or
snprintf will likely dump core. We need a lobotomized version that
doesn't attempt to fetch any of the variable parameters.
> This code runs completely under our control, and we can install whatever
> tools are needed. We don't need a C compiler today, but installing one
> is trivial. Also, we already have postgres source trees for each PG
> version available.
OK. I'd visualize only adding the test code to HEAD, and pulling it from
there to use for all back branches.
regards, tom lane