Re: [PATCHES] snprintf() argument reordering not working - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] snprintf() argument reordering not working
Date
Msg-id 29961.1133798174@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] snprintf() argument reordering not working  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [PATCHES] snprintf() argument reordering not working  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> What is more, when I set the locale of my machine to Turkish and run the 
> installer project's 8.1_RC1 which I happen to have installed there, and 
> set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
>   LOG:  "$s" veritaban?n transaction ID warp limiti $u
> I see this:
>   LOG:  "2147484146" veritabanin transaction ID warp limiti postgres

Well, that's pretty broken too :-(.  The tr.po file entry is
msgid "transaction ID wrap limit is %u, limited by database \"%s\""msgstr "\"%2$s\" veritabanın transaction ID warp
limiti%1$u"
 

and if I'm not completely confused, correct translated output would be
"postgres" veritabanın transaction ID warp limiti 2147484146

Nicolai's report looks a bit like what you would expect from an sprintf
implementation that hadn't heard of %n$ specs at all.  Your report looks
suspiciously like what our broken version of sprintf was producing last
week --- see
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00194.php

How certain are you that that config setting is inhibiting use of
port/snprintf.c?  It seems unlikely that any other implementation would
have duplicated our bug.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] snprintf() argument reordering not working
Next
From: Kevin Brown
Date:
Subject: Re: Reducing relation locking overhead