Re: [PATCHES] snprintf() argument reordering not working

I did some research and can report what was happening with *printf and
libintl.

Basically, there are two versions of libintl.  Versions before 0.13
(November 2003) use the libc version of *printf to handle printing of
translation strings.  Version 0.13 and after provide their own *printf
functions which understand %$ functionality.  The 0.13 change is:
 - C format strings with positions, as they arise when a translator needs to   reorder a sentence, are now supported on
allplatforms. On those few   platforms (NetBSD and Woe32) for which the native printf()/fprintf()/...   functions don't
supportsuch format strings, replacements are provided   through <libintl.h>.
 

In addition, reports in April 2003 that libintl did not compile with our
custom pg *printf functions on Win32 caused us to disable pg *printf
functions on Win32.  The assumption was that libintl had a special
*printf version to handle %$, but in fact only post-0.13 had that
feature.

If we had built pginstaller with a post-0.13 libintl, pginstaller would
have handled %$ translation strings fine.  The problem was that
pginstaller was built using pre-0.13 libintl, meaning it was using the
Win32 *printf, which doesn't understand %$.

Added to this was that our *printf functions had a bug that made %$ not
work.

Aside from fixing our own *printf, we have two ways of fixing this,
either use a post-0.13 version of libintl, or use the pre-0.13 libintl.

Based on risk analysis, we have chosen to continue using the same
pre-0.13 version of libintl, and to rely on our pg *printf functions to
handle %$.  We hope to put out a new pginstaller in the next few days
for testing to make sure this has been resolve before releasing 8.1.1.
---------------------------------------------------------------------------

Andrew Dunstan wrote:
> 
> 
> Tom Lane wrote:
> 
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >  
> >
> >>However, a very simple test shows that the libintl printf does indeed do 
> >>%m$ processing:
> >>...
> >>So the next question is why isn't it working in the build.
> >>    
> >>
> >
> >Is it possible that the build that was being complained of was using our
> >previous, very-broken snprintf.c?
> >
> >
> >  
> >
> 
> There's currently a config setting that is supposed to inhibit its use 
> on Windows. I am quite confused.
> 
> 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
> 
> So I'm inclined to think there might be something odd about his setup and maybe we aren't quite so broken after all.
> 
> cheers
> 
> andrew
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073