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

Greetings,

Last April we have made some changes to src/ports/snprintf.c so that it
would support argument reordering like %2$s, %1$d and such on
platforms where original snprintf() does not support it, like Windows,
HP-UX or NetBSD.

NLS messages of some languages, like Turkish, rely heavily on argument
reordering because of the language structure. In 8.1 Turkish messages
in Windows version are all broken because argument reordering is not there.

I examined commit logs and came to conclusion that src/port/snprintf.c
is not included in server when compiling under Windows because of change
to src/port/Makefile made in revision 1.28 by Bruce Momjian. See here:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/port/Makefile

Comment to the commit says:
`No server version of snprintf needed, so remove Makefile rule.'
In fact I think we need snprintf in server because NLS messages are
printed by the server.

Kindest regards,
Nicolai Tufar

Nicolai Tufar wrote:
> Greetings,
>
> Last April we have made some changes to src/ports/snprintf.c so that it
> would support argument reordering like %2$s, %1$d and such on
> platforms where original snprintf() does not support it, like Windows,
> HP-UX or NetBSD.

Sure, I remember. So glad you returned at this time. I found a design
limitation in that file yesterday. It can not output more then 4096
characters, and there are some cases with NUMERIC that try to output
more than that. For example:

SELECT pow(10::numeric, 10000) + 1;

should show a '1' at the end of the number, but with the existing code
you will just see 4095 0's and no more.

I am attaching the new snprintf.c and the patch itself for your review.
The change is to pass 'stream' down into the routines and output to the
FILE* right from inside the routine, rather than using a string. This
fixes the problem.

I am also thinking of modifying the code so if we are using snprintf.c
only because we need positional parameter control, we check for '$' in
the string and only use snprintf.c in those cases.

> NLS messages of some languages, like Turkish, rely heavily on argument
> reordering because of the language structure. In 8.1 Turkish messages
> in Windows version are all broken because argument reordering is not there.

Really? I have not heard any report of that but this is new code in 8.1.

> I examined commit logs and came to conclusion that src/port/snprintf.c
> is not included in server when compiling under Windows because of change
> to src/port/Makefile made in revision 1.28 by Bruce Momjian. See here:
>
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/port/Makefile
>
> Comment to the commit says:
> `No server version of snprintf needed, so remove Makefile rule.'
> In fact I think we need snprintf in server because NLS messages are
> printed by the server.

Actually, that changes means that there was nothing backend-specific in
snprintf.c so we don't need a _special_ version for the backend. The
real change not to use snprintf.c on Win32 is in configure.in with this
comment:

# Force use of our snprintf if system's doesn't do arg control
# This feature is used by NLS
if test "$enable_nls" = yes &&
test $pgac_need_repl_snprintf = no &&
# On Win32, libintl replaces snprintf() with its own version that
# understands arg control, so we don't need our own. In fact, it
# also uses macros that conflict with ours, so we _can't_ use
# our own.
test "$PORTNAME" != "win32"; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
fi
fi

Here is the commit:

revision 1.409
date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
On Win32, libintl replaces snprintf() with its own version that
understands arg control, so we don't need our own. In fact, it
also uses macros that conflict with ours, so we _can't_ use
our own.

So, I think it was Magnus who said that Win32 didn' need and couldn't
use our snprintf. Magnus, any ideas?

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I am also thinking of modifying the code so if we are using snprintf.c
> only because we need positional parameter control, we check for '$' in
> the string and only use snprintf.c in those cases.

What's the point? If the code is in there we may as well use it.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I am also thinking of modifying the code so if we are using snprintf.c
> > only because we need positional parameter control, we check for '$' in
> > the string and only use snprintf.c in those cases.
>
> What's the point? If the code is in there we may as well use it.

I was thinking it might avoid us hitting other bugs in there, but that
is pessimistic, of course. I will hold off on that idea.

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

Greetings,

I thought it will be as simple as changing Makefile, the issue seem to be
much more complicated. Unfortunately I have no PostgreSQL building
environment handy and will not be able to look at it until the end of next
week because I am moving my house :( But since this issue waited for so
long it may wait a week more.

2005/12/3, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>:
> Sure, I remember. So glad you returned at this time. I found a design
> limitation in that file yesterday. It can not output more then 4096
> characters, and there are some cases with NUMERIC that try to output
> more than that. For example:
>
> SELECT pow(10::numeric, 10000) + 1;
>
> should show a '1' at the end of the number, but with the existing code
> you will just see 4095 0's and no more.
>
> I am attaching the new snprintf.c and the patch itself for your review.
> The change is to pass 'stream' down into the routines and output to the
> FILE* right from inside the routine, rather than using a string. This
> fixes the problem.

Your patch increase buffers from 4095 to 8192. Sounds good to me.

> I am also thinking of modifying the code so if we are using snprintf.c
> only because we need positional parameter control, we check for '$' in
> the string and only use snprintf.c in those cases.

I too, was thinking of it at the beginning but decided that the code would
get even more complicated than it was at the moment and was afraid that
core team would not accept my patch. :)

> > NLS messages of some languages, like Turkish, rely heavily on argument
> > reordering because of the language structure. In 8.1 Turkish messages
> > in Windows version are all broken because argument reordering is not there.
>
> Really? I have not heard any report of that but this is new code in 8.1.

Windows installer does not set lc_messages configuration variable
correctly in postgresql.conf file. It is a known issue and will be solved
in next version. Meanwhile user needs to open postgresql.conf file
and change

lc_messages = 'Turkish_Turkey.28599'
to
lc_messages = 'tr_TR.UTF-8'

manually. Apparently nobody cared to do it and Devrim never ever touches
Windows. The problem is there, I am definitely positive about it, here are
two lines from log file:

2005-11-20 12:36:37 HATA: "$s" yerinde $s 1 karakterinde
2005-12-03 19:14:27 LOG: "$s" veritabanın transaction ID warp limiti $u

>
> Actually, that changes means that there was nothing backend-specific in
> snprintf.c so we don't need a _special_ version for the backend. The
> real change not to use snprintf.c on Win32 is in configure.in with this
> comment:
>
> # Force use of our snprintf if system's doesn't do arg control
> # This feature is used by NLS
> if test "$enable_nls" = yes &&
> test $pgac_need_repl_snprintf = no &&
> # On Win32, libintl replaces snprintf() with its own version that
> # understands arg control, so we don't need our own. In fact, it
> # also uses macros that conflict with ours, so we _can't_ use
> # our own.
> test "$PORTNAME" != "win32"; then
> PGAC_FUNC_PRINTF_ARG_CONTROL
> if test $pgac_cv_printf_arg_control != yes ; then
> pgac_need_repl_snprintf=yes
> fi
> fi
>
> Here is the commit:
>
> revision 1.409
> date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
> On Win32, libintl replaces snprintf() with its own version that
> understands arg control, so we don't need our own. In fact, it
> also uses macros that conflict with ours, so we _can't_ use
> our own.

I don't have MinGW build environment on my computer at the moment
and will not be able to install it until the end of next week but log messages
above were produced by PostgreSQL installed with 8.1.0-2 Windows installer
downloaded from postgresql.org. Since Turkish messages are printed
I suppose it was compiled with $enable_nls = yes

Thank you for your attention,
Regards,
Nicolai Tufar

Nicolai Tufar wrote:
> Greetings,
>
> I thought it will be as simple as changing Makefile, the issue seem to be
> much more complicated. Unfortunately I have no PostgreSQL building
> environment handy and will not be able to look at it until the end of next
> week because I am moving my house :( But since this issue waited for so
> long it may wait a week more.

Agreed. The problem is actually worse than I described --- see below.

> 2005/12/3, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>:
> > Sure, I remember. So glad you returned at this time. I found a design
> > limitation in that file yesterday. It can not output more then 4096
> > characters, and there are some cases with NUMERIC that try to output
> > more than that. For example:
> >
> > SELECT pow(10::numeric, 10000) + 1;
> >
> > should show a '1' at the end of the number, but with the existing code
> > you will just see 4095 0's and no more.
> >
> > I am attaching the new snprintf.c and the patch itself for your review.
> > The change is to pass 'stream' down into the routines and output to the
> > FILE* right from inside the routine, rather than using a string. This
> > fixes the problem.
>
> Your patch increase buffers from 4095 to 8192. Sounds good to me.

Well, that fixed-size buffer is now used only for sprintf(). The others
use the specified length (for snprintf()) or output directly to the
FILE* stream.

> > I am also thinking of modifying the code so if we are using snprintf.c
> > only because we need positional parameter control, we check for '$' in
> > the string and only use snprintf.c in those cases.
>
> I too, was thinking of it at the beginning but decided that the code would
> get even more complicated than it was at the moment and was afraid that
> core team would not accept my patch. :)

Seems Tom didn't like that and no one else has commented.

> > > NLS messages of some languages, like Turkish, rely heavily on argument
> > > reordering because of the language structure. In 8.1 Turkish messages
> > > in Windows version are all broken because argument reordering is not there.
> >
> > Really? I have not heard any report of that but this is new code in 8.1.
>
> Windows installer does not set lc_messages configuration variable
> correctly in postgresql.conf file. It is a known issue and will be solved
> in next version. Meanwhile user needs to open postgresql.conf file
> and change
>
> lc_messages = 'Turkish_Turkey.28599'
> to
> lc_messages = 'tr_TR.UTF-8'
>
> manually. Apparently nobody cared to do it and Devrim never ever touches
> Windows. The problem is there, I am definitely positive about it, here are
> two lines from log file:
>
> 2005-11-20 12:36:37 HATA: "$s" yerinde $s 1 karakterinde
> 2005-12-03 19:14:27 LOG: "$s" veritaban?n transaction ID warp limiti $u

OK.

> > Actually, that changes means that there was nothing backend-specific in
> > snprintf.c so we don't need a _special_ version for the backend. The
> > real change not to use snprintf.c on Win32 is in configure.in with this
> > comment:
> >
> > # Force use of our snprintf if system's doesn't do arg control
> > # This feature is used by NLS
> > if test "$enable_nls" = yes &&
> > test $pgac_need_repl_snprintf = no &&
> > # On Win32, libintl replaces snprintf() with its own version that
> > # understands arg control, so we don't need our own. In fact, it
> > # also uses macros that conflict with ours, so we _can't_ use
> > # our own.
> > test "$PORTNAME" != "win32"; then
> > PGAC_FUNC_PRINTF_ARG_CONTROL
> > if test $pgac_cv_printf_arg_control != yes ; then
> > pgac_need_repl_snprintf=yes
> > fi
> > fi
> >
> > Here is the commit:
> >
> > revision 1.409
> > date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
> > On Win32, libintl replaces snprintf() with its own version that
> > understands arg control, so we don't need our own. In fact, it
> > also uses macros that conflict with ours, so we _can't_ use
> > our own.
>
> I don't have MinGW build environment on my computer at the moment
> and will not be able to install it until the end of next week but log messages
> above were produced by PostgreSQL installed with 8.1.0-2 Windows installer
> downloaded from postgresql.org. Since Turkish messages are printed
> I suppose it was compiled with $enable_nls = yes

OK, here is what happened. In March 2005, we got reports of compile
problems on Win32 using NLS:

http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php

(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *printf calls with its own versions, and
does it using macros, _just_ like we do. This of course causes
conflicts and the system fails to compile. The _fix_ was to disable
port/*printf on Win32 when using NLS because NLS wants to use its own
*printf. I _assumed_ that libintl.h did this so it could use its own
routines that understood %$, but never verified that. It didn't seem we
had any choice to fix this, and got no problem reports about %$ not
working until yours.

After over a month with no solution I added the code as you see it now:

http://archives.postgresql.org/pgsql-hackers-win32/2005-05/msg00011.php

Oh, and it was Andrew Dunstan who worked on this, not Magnus. (Sorry
Magnus, Hello Andrew.)

Anyway, I think the big question is, was the pginstaller built with a
libintl that replaces *printf, and is it an *printf that doesn't
understand positional parameters, and so, how can we fix it.

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> (See the quoted text under the posted text as well.) Basically,
> libintl.h on Win32 replaces *printf calls with its own versions, and
> does it using macros, _just_ like we do. This of course causes
> conflicts and the system fails to compile. The _fix_ was to disable
> port/*printf on Win32 when using NLS because NLS wants to use its own
> *printf. I _assumed_ that libintl.h did this so it could use its own
> routines that understood %$, but never verified that.

Oops ... [ insert standard cliche about assumptions ]

It might be interesting to find out why libintl is replacing these
functions if not to support arg reordering, but I suppose the bottom
line will just be that Microsoft is as brain dead as usual :-(

> Anyway, I think the big question is, was the pginstaller built with a
> libintl that replaces *printf, and is it an *printf that doesn't
> understand positional parameters, and so, how can we fix it.

Would it work to modify c.h so that it #include's libintl.h, then #undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can work.

regards, tom lane

Bruce Momjian wrote:

>OK, here is what happened. In March 2005, we got reports of compile
>problems on Win32 using NLS:
>
> http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php
>
>(See the quoted text under the posted text as well.) Basically,
>libintl.h on Win32 replaces *printf calls with its own versions, and
>does it using macros, _just_ like we do. This of course causes
>conflicts and the system fails to compile. The _fix_ was to disable
>port/*printf on Win32 when using NLS because NLS wants to use its own
>*printf. I _assumed_ that libintl.h did this so it could use its own
>routines that understood %$, but never verified that. It didn't seem we
>had any choice to fix this, and got no problem reports about %$ not
>working until yours.
>
>After over a month with no solution I added the code as you see it now:
>
> http://archives.postgresql.org/pgsql-hackers-win32/2005-05/msg00011.php
>
>Oh, and it was Andrew Dunstan who worked on this, not Magnus. (Sorry
>Magnus, Hello Andrew.)
>
>Anyway, I think the big question is, was the pginstaller built with a
>libintl that replaces *printf, and is it an *printf that doesn't
>understand positional parameters, and so, how can we fix it.
>
>
>

Well , I diagnosed the problem - you're on your own as far as the
"solution" goes ;-)

On thing that seems clear to me is that we need a way of testing NLS
support.

Tom said:

>Would it work to modify c.h so that it #include's libintl.h, then #undefs
>these macros, then #includes port.h to define 'em the way we want?
>Some or all of this might need to be #ifdef WIN32, but that seems like
>a reasonably noninvasive solution if it can work.
>

IIRC last time I tried this it didn't work too well ;-( I will have
another go. I think it's the best way to go.

cheers

andrew

Andrew Dunstan wrote:

>
> Tom said:
>
>> Would it work to modify c.h so that it #include's libintl.h, then
>> #undefs
>> these macros, then #includes port.h to define 'em the way we want?
>> Some or all of this might need to be #ifdef WIN32, but that seems like
>> a reasonably noninvasive solution if it can work.
>>
>
> IIRC last time I tried this it didn't work too well ;-( I will have
> another go. I think it's the best way to go.
>
>

progress so far: I undid the config changes Bruce had made and undefined
printf, fprintf, sprintf, snprintf and vsnprintf after the include of
libintl.h in include/c.h. Then to clean up some warnings I undefined
vsnprintf and snprintf in interfaces/libpq/win32.h before their
redefinition.

That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> That got me through the backend compile and through libpq to ecpg, which
> fell over at the link stage complaining about missing references to
> pg_sprintf and pg_snprintf ... not sure how to fix that - windows
> experts, please advise.

Plan A would be to make libpq export pg_snprintf and friends, Plan B
would be to give ecpg its own copy of snprintf.o. Plan A is probably
better since you're going to hit the same issue no doubt in all of the
src/bin programs.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > That got me through the backend compile and through libpq to ecpg, which
> > fell over at the link stage complaining about missing references to
> > pg_sprintf and pg_snprintf ... not sure how to fix that - windows
> > experts, please advise.
>
> Plan A would be to make libpq export pg_snprintf and friends, Plan B
> would be to give ecpg its own copy of snprintf.o. Plan A is probably
> better since you're going to hit the same issue no doubt in all of the
> src/bin programs.

I am confused why we would need either of these. All apps use
libpgport, and that pg_*printf should be in that library. The original
work Andrew did has problems particularly with ecpg, but why does ecpg
cause problems? Doesn't it link in pgport?

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

Bruce Momjian wrote:

>Tom Lane wrote:
>
>
>>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>
>>>That got me through the backend compile and through libpq to ecpg, which
>>>fell over at the link stage complaining about missing references to
>>>pg_sprintf and pg_snprintf ... not sure how to fix that - windows
>>>experts, please advise.
>>>
>>>
>>Plan A would be to make libpq export pg_snprintf and friends, Plan B
>>would be to give ecpg its own copy of snprintf.o. Plan A is probably
>>better since you're going to hit the same issue no doubt in all of the
>>src/bin programs.
>>
>>
>
>I am confused why we would need either of these. All apps use
>libpgport, and that pg_*printf should be in that library. The original
>work Andrew did has problems particularly with ecpg, but why does ecpg
>cause problems? Doesn't it link in pgport?
>
>
>

libpgtypes doesn't link with either libpgport or libpq.

What I have done to get a working build in addition to the previous
report is to undef snprintf and sprintf in
interfaces/pgtypeslib/extern.h (instead of creating an additional link
burden), and to add entries for pg_snprintf, pg_sprintf and pg_fprintf
to interfaces/libpq/exports.txt. That let me get a clean compile and
regression run. The diff against 8.1 is attached for comment.

I suspect we should probably add all the pg_*printf functions to
exports.txt.

(Of course, first you need to install gettext and libintl from the
gnuwin32 project, or you can't even configure with --enable-nls)

cheers

andrew

OK, a few things. First, Tom has fixed snprintf.c so it should properly
process positional parameters now. Would you first test the libintl
version of *printf to see if it can process %$ parameters (probably by
hacking up any language file and testing the printing), and then try
your patch below to see if it is properly reorders the arguments. If
libintl does not reorder properly, but our snprintf.c does, would you
please generate an appliable patch we can put into 8.1.X? Thanks.

I know I am asking a lot, but you are "the man" on this one. :-)

---------------------------------------------------------------------------

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >Tom Lane wrote:
> >
> >
> >>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >>
> >>
> >>>That got me through the backend compile and through libpq to ecpg, which
> >>>fell over at the link stage complaining about missing references to
> >>>pg_sprintf and pg_snprintf ... not sure how to fix that - windows
> >>>experts, please advise.
> >>>
> >>>
> >>Plan A would be to make libpq export pg_snprintf and friends, Plan B
> >>would be to give ecpg its own copy of snprintf.o. Plan A is probably
> >>better since you're going to hit the same issue no doubt in all of the
> >>src/bin programs.
> >>
> >>
> >
> >I am confused why we would need either of these. All apps use
> >libpgport, and that pg_*printf should be in that library. The original
> >work Andrew did has problems particularly with ecpg, but why does ecpg
> >cause problems? Doesn't it link in pgport?
> >
> >
> >
>
>
>
> libpgtypes doesn't link with either libpgport or libpq.
>
> What I have done to get a working build in addition to the previous
> report is to undef snprintf and sprintf in
> interfaces/pgtypeslib/extern.h (instead of creating an additional link
> burden), and to add entries for pg_snprintf, pg_sprintf and pg_fprintf
> to interfaces/libpq/exports.txt. That let me get a clean compile and
> regression run. The diff against 8.1 is attached for comment.
>
> I suspect we should probably add all the pg_*printf functions to
> exports.txt.
>
> (Of course, first you need to install gettext and libintl from the
> gnuwin32 project, or you can't even configure with --enable-nls)
>
> cheers
>
> andrew
>
>

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

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

Bruce Momjian said:
>
> OK, a few things. First, Tom has fixed snprintf.c so it should
> properly process positional parameters now. Would you first test the
> libintl version of *printf to see if it can process %$ parameters
> (probably by hacking up any language file and testing the printing),
> and then try your patch below to see if it is properly reorders the
> arguments. If libintl does not reorder properly, but our snprintf.c
> does, would you please generate an appliable patch we can put into
> 8.1.X? Thanks.
>
> I know I am asking a lot, but you are "the man" on this one. :-)
>

Since the effect of the configure change I am proposing to reverse was to
force use of the *printf in libintl, don't we already know the answer to
your first question from Nicolai's report?

cheers

andrew

I wrote:

>Bruce Momjian said:
>
>
>>OK, a few things. First, Tom has fixed snprintf.c so it should
>>properly process positional parameters now. Would you first test the
>>libintl version of *printf to see if it can process %$ parameters
>>(probably by hacking up any language file and testing the printing),
>>and then try your patch below to see if it is properly reorders the
>>arguments. If libintl does not reorder properly, but our snprintf.c
>>does, would you please generate an appliable patch we can put into
>>8.1.X? Thanks.
>>
>>I know I am asking a lot, but you are "the man" on this one. :-)
>>
>>
>>
>
>Since the effect of the configure change I am proposing to reverse was to
>force use of the *printf in libintl, don't we already know the answer to
>your first question from Nicolai's report?
>
>
>
>

However, a very simple test shows that the libintl printf does indeed do
%m$ processing:

$ cat testpf.c
#include <libintl.h>
main()
{
printf("%2$s %1$s\n","arg1","arg2");
}
$ gcc -o testpf testpf.c -lintl
$ ./testpf.exe
arg2 arg1
$

So the next question is why isn't it working in the build.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)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?

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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

Andrew Dunstan <andrew(at)dunslane(dot)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\" veritabann transaction ID warp limiti %1$u"

and if I'm not completely confused, correct translated output would be

"postgres" veritabann 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

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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.
>
>

Sorry ... I got into a muddle. I have rerun the tests.

With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took). I will
now try to verify that the changes you made in pg_sprintf do the right
thing.

We could ask why it appears that one version of libintl works (the one I
got the other day from gnuwin32) and one doesn't (the one that is in the
installer, apparently).

But the simple fix seems to be to use our version of printf and friends.
The changes requires are not too invasive.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
> made yesterday, I see the result above, i.e. what we expect from our own
> breakage of sprintf (i haven't yet updated the snapshot I took).

Ah. OK, that makes sense.

> But the simple fix seems to be to use our version of printf and friends.
> The changes requires are not too invasive.

I agree with doing this even if we weren't faced with (apparently)
multiple versions of libintl that don't all work alike. My thought is
that running our own version of snprintf on a heavily used port like
Windows is exactly what is needed to flush out any remaining bugs.
It's obviously not gotten enough field usage yet ...

Was the last patch you sent in ready for application, or are you still
fooling with it?

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
> > made yesterday, I see the result above, i.e. what we expect from our own
> > breakage of sprintf (i haven't yet updated the snapshot I took).
>
> Ah. OK, that makes sense.
>
> > But the simple fix seems to be to use our version of printf and friends.
> > The changes requires are not too invasive.
>
> I agree with doing this even if we weren't faced with (apparently)
> multiple versions of libintl that don't all work alike. My thought is
> that running our own version of snprintf on a heavily used port like
> Windows is exactly what is needed to flush out any remaining bugs.
> It's obviously not gotten enough field usage yet ...
>
> Was the last patch you sent in ready for application, or are you still
> fooling with it?

He is still working on it. It did not handle all *printf functions, as
he mentioned, and he might have other changes.

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

Bruce Momjian wrote:

>>Was the last patch you sent in ready for application, or are you still
>>fooling with it?
>>
>>
>
>He is still working on it. It did not handle all *printf functions, as
>he mentioned, and he might have other changes.
>
>
>

Yeah.

The good news: the new pg_*printf does the right thing for the %m$
parameters in the Turkish locale.

The bad news: if we aren't compiling with NLS enabled, having those
entries in exports.txt makes the libpq build blow up. So either we need
to use pg_*printf unconditionally on Windows, or we need a little
Makefile + sed magic to strip those entries out of exports.txt when it
is used, if we're not doing NLS, or something of that kind.

Question: do the entries in exports.txt have to be numbered
consecutively, or just uniquely?

With luck I can probably wrap this up today for the 8.1 stable branch -
it would be nice if the new release actually did NLS right.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> The bad news: if we aren't compiling with NLS enabled, having those
> entries in exports.txt makes the libpq build blow up. So either we need
> to use pg_*printf unconditionally on Windows, or we need a little
> Makefile + sed magic to strip those entries out of exports.txt when it
> is used, if we're not doing NLS, or something of that kind.

I think it's a bad idea for exports.txt not to be the same in all
builds. So yeah, if we export these names at all then it has to be
unconditional.

What about Plan B? Per Bruce's comment, it should really only be ecpg
that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
already pull in various port/ files for itself.

regards, tom lane

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> With luck I can probably wrap this up today for the 8.1 stable branch -
> it would be nice if the new release actually did NLS right.

BTW, core has already agreed to postpone the releases a couple days
while we make sure we have this problem nailed down.

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>The bad news: if we aren't compiling with NLS enabled, having those
>>entries in exports.txt makes the libpq build blow up. So either we need
>>to use pg_*printf unconditionally on Windows, or we need a little
>>Makefile + sed magic to strip those entries out of exports.txt when it
>>is used, if we're not doing NLS, or something of that kind.
>>
>>
>
>I think it's a bad idea for exports.txt not to be the same in all
>builds. So yeah, if we export these names at all then it has to be
>unconditional.
>
>What about Plan B? Per Bruce's comment, it should really only be ecpg
>that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
>already pull in various port/ files for itself.
>
>
>
>

The problem is that the alias will be picked up by every libpq client. I
got around the problem with ecpg's libpgtypes by unaliasing sprintf and
snprintf. But we can't do that everywhere.

I'm not sure I see the objection to stripping these out of the *.def files.

I can't spend any more time on this now - I have spent far too much on
it already. My working patch is attached. Maybe I can look at it again
in a few days.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> What about Plan B? Per Bruce's comment, it should really only be ecpg
>> that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
>> already pull in various port/ files for itself.

> The problem is that the alias will be picked up by every libpq client.

Not at all; libpq clients do not import c.h.

regards, tom lane

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> The problem is that the alias will be picked up by every libpq client.
>>
>> Not at all; libpq clients do not import c.h.

> Well, all the programs that use postgres-fe.h do.

Sure, but all of them do (or should) include libpgport and can get at
the functions from that.

> I'm coming around to thinking that the simple solution is just to use it
> unconditionally on Windows.

I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to our client-side programs via libpq.

regards, tom lane

Tom Lane wrote:

>>I'm coming around to thinking that the simple solution is just to use it
>>unconditionally on Windows.
>>
>>
>
>I agree that that's what we should do, but it should be done the same
>way we handle other routines from libpgport. None of those are exported
>to our client-side programs via libpq.
>
>
>
>

OK, eyeball this for the REL8_1_STABLE branch, please. It seems to work
for me. No exports necessary.

cheers

andrew

Andrew Dunstan wrote:

>
>
> Tom Lane wrote:
>
>>> I'm coming around to thinking that the simple solution is just to
>>> use it unconditionally on Windows.
>>>
>>
>>
>> I agree that that's what we should do, but it should be done the same
>> way we handle other routines from libpgport. None of those are exported
>> to our client-side programs via libpq.
>>
>>
>>
>>
>
> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
> work for me. No exports necessary.
>
>

er try this instead. I missed a line from configure.in

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to work
> for me. No exports necessary.

OK, I see a few cleanups I want to make, but given the knowledge that
this patch does work on Win32, I should be able to get it done tonight.
Thanks for doing the legwork!

regards, tom lane

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
>> work for me. No exports necessary.

> er try this instead. I missed a line from configure.in

I cleaned this up slightly and committed it into HEAD and 8.1 branches.
It appears to work in that I can force pgac_need_repl_snprintf to "yes"
on a Linux machine and get a working build. But we need to verify that
things are OK on Windows, both with the old libintl that the installer
is using and with current libintl. Please build and test ...

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>>OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
>>>work for me. No exports necessary.
>>>
>>>
>
>
>
>>er try this instead. I missed a line from configure.in
>>
>>
>
>I cleaned this up slightly and committed it into HEAD and 8.1 branches.
>It appears to work in that I can force pgac_need_repl_snprintf to "yes"
>on a Linux machine and get a working build. But we need to verify that
>things are OK on Windows, both with the old libintl that the installer
>is using and with current libintl. Please build and test ...
>
>

the cleanup seems to have omitted the change I had to
src/interfaces/ecpg/pgtypeslib/extern.h, which causes a build failure - see

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-06%2003:30:36

If we don't do this then we need to link snprintf into libpgtypes just
like we do for ecpg, but it seems like overkill.

cheers

andrew

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 all platforms. On those few
platforms (NetBSD and Woe32) for which the native printf()/fprintf()/...
functions don't support such 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(at)dunslane(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Also, we need a way to stop this from happening all over the build:

> In file included from ../../../../../../src/include/c.h:820,
> from ../../../../../../src/include/postgres.h:48,
> from utf8_and_sjis.c:14:
> ../../../../../../src/include/port.h:121: warning: `libintl_printf' is an unrecognized format function type

Argh, I ordered things wrong: should undef the old macros before
declaring the new functions.

Not sure why my build didn't show the problem in pgtypeslib, though.
That should have failed with or without libintl macros.

regards, tom lane

Tom Lane wrote:

>Not sure why my build didn't show the problem in pgtypeslib, though.
>That should have failed with or without libintl macros.
>
>
>
>

On *nix it probably just thinks it's an external symbol to be resolved
later.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> If we don't do this then we need to link snprintf into libpgtypes just
> like we do for ecpg, but it seems like overkill.

It might be overkill today, but what about tomorrow when someone decides
to internationalize libpgtypes? I made it link in there too. Please
test ...

regards, tom lane

2005/12/4, Andrew Dunstan <andrew(at)dunslane(dot)net>:
> Tom said:
>
> >Would it work to modify c.h so that it #include's libintl.h, then #undefs
> >these macros, then #includes port.h to define 'em the way we want?
> >Some or all of this might need to be #ifdef WIN32, but that seems like
> >a reasonably noninvasive solution if it can work.
> >
>
> IIRC last time I tried this it didn't work too well ;-( I will have
> another go. I think it's the best way to go.

Very well, I will try to put up a patch to implement it in a couple of days.

>
> cheers
>
> andrew
>

2005/12/6, Nicolai Tufar <ntufar(at)gmail(dot)com>:
> >
> > IIRC last time I tried this it didn't work too well ;-( I will have
> > another go. I think it's the best way to go.
>
> Very well, I will try to put up a patch to implement it in a couple of days.

Oh boy, it is already fixed. Sorry folks, my error.
Many thanks to Bruce, Tom and Andrew!
Turksh Windows user can breathe easier now.

Sincerely,
Nicolai Tufar

Tom Lane wrote:

> Please test ...
>
>

Well, if you look here you'll see a bunch of Turkish messages, because I
forgot to change the locale back ;-)

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-06%2011:57:20

Which raises another question: can we force the locale on Windows, or
are we stuck with the locale that the machine is set to? But maybe that
belongs in another thread.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Which raises another question: can we force the locale on Windows, or
> are we stuck with the locale that the machine is set to? But maybe that
> belongs in another thread.

I thought we'd put in some sort of "no-locale" switch specifically for
the buildfarm to use on Windows? I recall talking about it anyway ...

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>Which raises another question: can we force the locale on Windows, or
>>are we stuck with the locale that the machine is set to? But maybe that
>>belongs in another thread.
>>
>>
>
>I thought we'd put in some sort of "no-locale" switch specifically for
>the buildfarm to use on Windows? I recall talking about it anyway ...
>
>
>
>

Yeah, but I'm not sure it's working. I will look into it.

cheers

andrew

Andrew Dunstan wrote:

> Tom Lane wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>
>>> Which raises another question: can we force the locale on Windows,
>>> or are we stuck with the locale that the machine is set to? But
>>> maybe that belongs in another thread.
>>>
>>
>> I thought we'd put in some sort of "no-locale" switch specifically for
>> the buildfarm to use on Windows? I recall talking about it anyway ...
>>
>
> Yeah, but I'm not sure it's working. I will look into it.

*sheepish look*

I committed the pg_regress change back in Nov but didn't change
buildfarm to use it. And now I look at it more closely I think it won't
work. We have:

/ # locale
/ NOLOCALE :=
ifdef NO_LOCALE
NOLOCALE += --no-locale
endif

I think instead of the += line we need:

override NOLOCALE := --nolocale

The intended effect is that if any NOLOCALE arg is used in invoking
make, --no-locale gets passed to pg_regress.

cheers

andrew

Andrew Dunstan wrote:

>
>
>
> I committed the pg_regress change back in Nov but didn't change
> buildfarm to use it. And now I look at it more closely I think it
> won't work. We have:
>
> / # locale
> / NOLOCALE :=
> ifdef NO_LOCALE
> NOLOCALE += --no-locale
> endif
>
> I think instead of the += line we need:
>
> override NOLOCALE := --nolocale
>
>

and if I look after I have had some coffee I will see the underscore I
missed that makes it make sense. We now return you to your regular viewing.

cheers

andrew