Обсуждение: Re: [PATCHES] snprintf() argument reordering not working under

Поиск
Список
Период
Сортировка

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

От
Bruce Momjian
Дата:
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@candle.pha.pa.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@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
 


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

От
Tom Lane
Дата:
Bruce Momjian <pgman@candle.pha.pa.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


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

От
Andrew Dunstan
Дата:

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


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

От
Andrew Dunstan
Дата:

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



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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Bruce Momjian
Дата:
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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@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
 


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

От
Andrew Dunstan
Дата:

Bruce Momjian wrote:

>Tom Lane wrote:
>
>
>>Andrew Dunstan <andrew@dunslane.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


Index: configure
===================================================================
RCS file: /projects/cvsroot/pgsql/configure,v
retrieving revision 1.461
diff -c -r1.461 configure
*** configure    5 Nov 2005 04:01:38 -0000    1.461
--- configure    4 Dec 2005 22:56:58 -0000
***************
*** 17111,17123 ****

  # 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
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
--- 17111,17117 ----

  # 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 ; then
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
Index: src/include/c.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.190
diff -c -r1.190 c.h
*** src/include/c.h    15 Oct 2005 02:49:41 -0000    1.190
--- src/include/c.h    4 Dec 2005 22:57:02 -0000
***************
*** 96,101 ****
--- 96,122 ----

  #ifdef ENABLE_NLS
  #include <libintl.h>
+ #ifdef WIN32
+ #ifdef USE_SNPRINTF
+
+ #ifdef printf
+ #undef printf
+ #endif
+ #ifdef fprintf
+ #undef fprintf
+ #endif
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+
+ #endif
+ #endif
  #else
  #define gettext(x) (x)
  #endif
Index: src/interfaces/ecpg/pgtypeslib/extern.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/extern.h,v
retrieving revision 1.7
diff -c -r1.7 extern.h
*** src/interfaces/ecpg/pgtypeslib/extern.h    15 Oct 2005 02:49:47 -0000    1.7
--- src/interfaces/ecpg/pgtypeslib/extern.h    4 Dec 2005 22:57:05 -0000
***************
*** 1,6 ****
--- 1,14 ----
  #ifndef __PGTYPES_COMMON_H__
  #define __PGTYPES_COMMON_H__

+
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+
  #include "pgtypes_error.h"

  /* These are the constants that decide which printf() format we'll use in
Index: src/interfaces/libpq/exports.txt
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.5
diff -c -r1.5 exports.txt
*** src/interfaces/libpq/exports.txt    21 Oct 2005 15:21:21 -0000    1.5
--- src/interfaces/libpq/exports.txt    4 Dec 2005 22:57:06 -0000
***************
*** 125,127 ****
--- 125,130 ----
  lo_create                 123
  PQinitSSL                 124
  PQregisterThreadLock      125
+ pg_sprintf          126
+ pg_snprintf          127
+ pg_fprintf          128
Index: src/interfaces/libpq/win32.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/win32.h,v
retrieving revision 1.27
diff -c -r1.27 win32.h
*** src/interfaces/libpq/win32.h    31 Jul 2004 06:19:23 -0000    1.27
--- src/interfaces/libpq/win32.h    4 Dec 2005 22:57:06 -0000
***************
*** 16,21 ****
--- 16,27 ----
  #define write(a,b,c) _write(a,b,c)
  #endif

+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
  #define vsnprintf(a,b,c,d) _vsnprintf(a,b,c,d)
  #define snprintf _snprintf


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

От
Bruce Momjian
Дата:
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@dunslane.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@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
 


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

От
"Andrew Dunstan"
Дата:
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




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

От
Andrew Dunstan
Дата:
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





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

От
Tom Lane
Дата:
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?
        regards, tom lane


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

От
Andrew Dunstan
Дата:

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


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

От
Tom Lane
Дата:
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


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

От
Andrew Dunstan
Дата:

Tom Lane wrote:

>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.
>  
>


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


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Bruce Momjian
Дата:
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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@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
 


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

От
Andrew Dunstan
Дата:

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


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Andrew Dunstan
Дата:

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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
Index: configure
===================================================================
RCS file: /projects/cvsroot/pgsql/configure,v
retrieving revision 1.461
diff -c -r1.461 configure
*** configure    5 Nov 2005 04:01:38 -0000    1.461
--- configure    5 Dec 2005 18:56:04 -0000
***************
*** 17111,17123 ****

  # 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
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
--- 17111,17117 ----

  # 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 ; then
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
Index: src/include/c.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.190
diff -c -r1.190 c.h
*** src/include/c.h    15 Oct 2005 02:49:41 -0000    1.190
--- src/include/c.h    5 Dec 2005 18:56:23 -0000
***************
*** 96,101 ****
--- 96,122 ----

  #ifdef ENABLE_NLS
  #include <libintl.h>
+ #ifdef WIN32
+ #ifdef USE_SNPRINTF
+
+ #ifdef printf
+ #undef printf
+ #endif
+ #ifdef fprintf
+ #undef fprintf
+ #endif
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+
+ #endif
+ #endif
  #else
  #define gettext(x) (x)
  #endif
Index: src/interfaces/ecpg/pgtypeslib/extern.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/extern.h,v
retrieving revision 1.7
diff -c -r1.7 extern.h
*** src/interfaces/ecpg/pgtypeslib/extern.h    15 Oct 2005 02:49:47 -0000    1.7
--- src/interfaces/ecpg/pgtypeslib/extern.h    5 Dec 2005 18:56:24 -0000
***************
*** 1,6 ****
--- 1,14 ----
  #ifndef __PGTYPES_COMMON_H__
  #define __PGTYPES_COMMON_H__

+
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+
  #include "pgtypes_error.h"

  /* These are the constants that decide which printf() format we'll use in
Index: src/interfaces/libpq/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/Makefile,v
retrieving revision 1.138
diff -c -r1.138 Makefile
*** src/interfaces/libpq/Makefile    29 Aug 2005 00:47:35 -0000    1.138
--- src/interfaces/libpq/Makefile    5 Dec 2005 18:56:24 -0000
***************
*** 25,30 ****
--- 25,34 ----
  override CFLAGS += $(PTHREAD_CFLAGS)
  endif

+ ifneq ($(enable_nls), yes)
+ NONLS = -e '/^pg_.*printf/d'
+ endif
+
  # Need to recomple any libpgport object files
  LIBS := $(patsubst -lpgport,, $(LIBS))

***************
*** 103,126 ****
      echo 'LIBRARY LIBPQ' >> $@
      echo 'DESCRIPTION "PostgreSQL Client Library"' >> $@
      echo 'EXPORTS' >> $@
!     sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    \1@ \2/' < $< >> $@

  $(srcdir)/libpqddll.def: exports.txt
      echo '; DEF file for MS VC++' > $@
      echo 'LIBRARY LIBPQD' >> $@
      echo 'DESCRIPTION "PostgreSQL Client Library"' >> $@
      echo 'EXPORTS' >> $@
!     sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    \1@ \2/' < $< >> $@

  $(srcdir)/blibpqdll.def: exports.txt
      echo '; DEF file for Borland C++ Builder' > $@
      echo 'LIBRARY BLIBPQ' >> $@
      echo 'DESCRIPTION "PostgreSQL Client Library"' >> $@
      echo 'EXPORTS' >> $@
!     sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    _\1@ \2/' < $< >> $@
      echo '' >> $@
      echo '; Aliases for MS compatible names' >> $@
!     sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    \1= _\1/' < $< | sed 's/ *$$//' >> $@

  # depend on Makefile.global to force rebuild on re-run of configure
  $(srcdir)/libpq.rc: libpq.rc.in $(top_builddir)/src/Makefile.global
--- 107,130 ----
      echo 'LIBRARY LIBPQ' >> $@
      echo 'DESCRIPTION "PostgreSQL Client Library"' >> $@
      echo 'EXPORTS' >> $@
!     sed $(NONLS) -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    \1@ \2/' < $< >> $@

  $(srcdir)/libpqddll.def: exports.txt
      echo '; DEF file for MS VC++' > $@
      echo 'LIBRARY LIBPQD' >> $@
      echo 'DESCRIPTION "PostgreSQL Client Library"' >> $@
      echo 'EXPORTS' >> $@
!     sed $(NONLS) -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    \1@ \2/' < $< >> $@

  $(srcdir)/blibpqdll.def: exports.txt
      echo '; DEF file for Borland C++ Builder' > $@
      echo 'LIBRARY BLIBPQ' >> $@
      echo 'DESCRIPTION "PostgreSQL Client Library"' >> $@
      echo 'EXPORTS' >> $@
!     sed $(NONLS) -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    _\1@ \2/' < $< >> $@
      echo '' >> $@
      echo '; Aliases for MS compatible names' >> $@
!     sed $(NONLS) -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/    \1= _\1/' < $< | sed 's/ *$$//' >> $@

  # depend on Makefile.global to force rebuild on re-run of configure
  $(srcdir)/libpq.rc: libpq.rc.in $(top_builddir)/src/Makefile.global
Index: src/interfaces/libpq/exports.txt
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.5
diff -c -r1.5 exports.txt
*** src/interfaces/libpq/exports.txt    21 Oct 2005 15:21:21 -0000    1.5
--- src/interfaces/libpq/exports.txt    5 Dec 2005 18:56:24 -0000
***************
*** 125,127 ****
--- 125,132 ----
  lo_create                 123
  PQinitSSL                 124
  PQregisterThreadLock      125
+ pg_sprintf                126
+ pg_snprintf               127
+ pg_fprintf                128
+ pg_printf                 129
+ pg_vsnprintf              130
Index: src/interfaces/libpq/win32.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/win32.h,v
retrieving revision 1.27
diff -c -r1.27 win32.h
*** src/interfaces/libpq/win32.h    31 Jul 2004 06:19:23 -0000    1.27
--- src/interfaces/libpq/win32.h    5 Dec 2005 18:56:24 -0000
***************
*** 16,21 ****
--- 16,27 ----
  #define write(a,b,c) _write(a,b,c)
  #endif

+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
  #define vsnprintf(a,b,c,d) _vsnprintf(a,b,c,d)
  #define snprintf _snprintf


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.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


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

От
Andrew Dunstan
Дата:

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
? autom4te.cache
Index: configure
===================================================================
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.461
diff -c -r1.461 configure
*** configure    5 Nov 2005 04:01:38 -0000    1.461
--- configure    5 Dec 2005 22:22:11 -0000
***************
*** 13851,13858 ****
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.

! pgac_need_repl_snprintf=no

  for ac_func in snprintf
  do
--- 13851,13861 ----
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.
+ # Win32 gets this built unconditionally

! if test "$PORTNAME" = "win32"; then
!   pgac_need_repl_snprintf=yes
! else

  for ac_func in snprintf
  do
***************
*** 14061,14066 ****
--- 14064,14070 ----
  fi
  done

+ fi


  # Check whether <stdio.h> declares snprintf() and vsnprintf(); if not,
***************
*** 17111,17123 ****

  # 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
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
--- 17115,17121 ----

  # 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 ; then
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.431
diff -c -r1.431 configure.in
*** configure.in    5 Nov 2005 04:01:41 -0000    1.431
--- configure.in    5 Dec 2005 22:22:12 -0000
***************
*** 849,858 ****
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.

! pgac_need_repl_snprintf=no
! AC_CHECK_FUNCS(snprintf, [], pgac_need_repl_snprintf=yes)
! AC_CHECK_FUNCS(vsnprintf, [], pgac_need_repl_snprintf=yes)


  # Check whether <stdio.h> declares snprintf() and vsnprintf(); if not,
--- 849,862 ----
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.
+ # Win32 gets this built unconditionally

! if test "$PORTNAME" = "win32"; then
!   pgac_need_repl_snprintf=yes
! else
!   AC_CHECK_FUNCS(snprintf, [], pgac_need_repl_snprintf=yes)
!   AC_CHECK_FUNCS(vsnprintf, [], pgac_need_repl_snprintf=yes)
! fi


  # Check whether <stdio.h> declares snprintf() and vsnprintf(); if not,
***************
*** 1046,1058 ****

  # 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
--- 1050,1056 ----

  # 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 ; then
    PGAC_FUNC_PRINTF_ARG_CONTROL
    if test $pgac_cv_printf_arg_control != yes ; then
      pgac_need_repl_snprintf=yes
Index: src/include/c.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.190
diff -c -r1.190 c.h
*** src/include/c.h    15 Oct 2005 02:49:41 -0000    1.190
--- src/include/c.h    5 Dec 2005 22:22:16 -0000
***************
*** 96,101 ****
--- 96,122 ----

  #ifdef ENABLE_NLS
  #include <libintl.h>
+ #ifdef WIN32
+ #ifdef USE_SNPRINTF
+
+ #ifdef printf
+ #undef printf
+ #endif
+ #ifdef fprintf
+ #undef fprintf
+ #endif
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+
+ #endif
+ #endif
  #else
  #define gettext(x) (x)
  #endif
Index: src/interfaces/ecpg/ecpglib/Makefile
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/Makefile,v
retrieving revision 1.33
diff -c -r1.33 Makefile
*** src/interfaces/ecpg/ecpglib/Makefile    14 Mar 2005 17:27:50 -0000    1.33
--- src/interfaces/ecpg/ecpglib/Makefile    5 Dec 2005 22:22:17 -0000
***************
*** 33,38 ****
--- 33,40 ----
  ifeq ($(PORTNAME), win32)
  # Link to shfolder.dll instead of shell32.dll
  SHLIB_LINK += -lshfolder
+ # and use our snprintf
+ OBJS += snprintf.o
  endif

  all: all-lib
***************
*** 51,56 ****
--- 53,61 ----
  exec.c: % : $(top_srcdir)/src/port/%
      rm -f $@ && $(LN_S) $< .

+ snprintf.c: % : $(top_srcdir)/src/port/%
+     rm -f $@ && $(LN_S) $< .
+
  path.o: path.c $(top_builddir)/src/port/pg_config_paths.h

  $(top_builddir)/src/port/pg_config_paths.h:
Index: src/interfaces/ecpg/pgtypeslib/extern.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/extern.h,v
retrieving revision 1.7
diff -c -r1.7 extern.h
*** src/interfaces/ecpg/pgtypeslib/extern.h    15 Oct 2005 02:49:47 -0000    1.7
--- src/interfaces/ecpg/pgtypeslib/extern.h    5 Dec 2005 22:22:17 -0000
***************
*** 1,6 ****
--- 1,14 ----
  #ifndef __PGTYPES_COMMON_H__
  #define __PGTYPES_COMMON_H__

+
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+
  #include "pgtypes_error.h"

  /* These are the constants that decide which printf() format we'll use in
Index: src/interfaces/libpq/win32.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/win32.h,v
retrieving revision 1.27
diff -c -r1.27 win32.h
*** src/interfaces/libpq/win32.h    31 Jul 2004 06:19:23 -0000    1.27
--- src/interfaces/libpq/win32.h    5 Dec 2005 22:22:18 -0000
***************
*** 16,21 ****
--- 16,27 ----
  #define write(a,b,c) _write(a,b,c)
  #endif

+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
  #define vsnprintf(a,b,c,d) _vsnprintf(a,b,c,d)
  #define snprintf _snprintf


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

От
Andrew Dunstan
Дата:

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
? autom4te.cache
Index: configure
===================================================================
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.461
diff -c -r1.461 configure
*** configure    5 Nov 2005 04:01:38 -0000    1.461
--- configure    5 Dec 2005 22:39:43 -0000
***************
*** 13851,13858 ****
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.

! pgac_need_repl_snprintf=no

  for ac_func in snprintf
  do
--- 13851,13862 ----
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.
+ # Win32 gets this built unconditionally

! if test "$PORTNAME" = "win32"; then
!   pgac_need_repl_snprintf=yes
! else
!   pgac_need_repl_snprintf=no

  for ac_func in snprintf
  do
***************
*** 14061,14066 ****
--- 14065,14071 ----
  fi
  done

+ fi


  # Check whether <stdio.h> declares snprintf() and vsnprintf(); if not,
***************
*** 17111,17123 ****

  # 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
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
--- 17116,17122 ----

  # 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 ; then
    echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
  echo $ECHO_N "checking whether printf supports argument control... $ECHO_C" >&6
  if test "${pgac_cv_printf_arg_control+set}" = set; then
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.431
diff -c -r1.431 configure.in
*** configure.in    5 Nov 2005 04:01:41 -0000    1.431
--- configure.in    5 Dec 2005 22:39:44 -0000
***************
*** 849,858 ****
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.

! pgac_need_repl_snprintf=no
! AC_CHECK_FUNCS(snprintf, [], pgac_need_repl_snprintf=yes)
! AC_CHECK_FUNCS(vsnprintf, [], pgac_need_repl_snprintf=yes)


  # Check whether <stdio.h> declares snprintf() and vsnprintf(); if not,
--- 849,863 ----
  # is missing.  Yes, there are machines that have only one.  We may
  # also decide to use snprintf.c if snprintf() is present but does not
  # have all the features we need --- see below.
+ # Win32 gets this built unconditionally

! if test "$PORTNAME" = "win32"; then
!   pgac_need_repl_snprintf=yes
! else
!   pgac_need_repl_snprintf=no
!   AC_CHECK_FUNCS(snprintf, [], pgac_need_repl_snprintf=yes)
!   AC_CHECK_FUNCS(vsnprintf, [], pgac_need_repl_snprintf=yes)
! fi


  # Check whether <stdio.h> declares snprintf() and vsnprintf(); if not,
***************
*** 1046,1058 ****

  # 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
--- 1051,1057 ----

  # 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 ; then
    PGAC_FUNC_PRINTF_ARG_CONTROL
    if test $pgac_cv_printf_arg_control != yes ; then
      pgac_need_repl_snprintf=yes
Index: src/include/c.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.190
diff -c -r1.190 c.h
*** src/include/c.h    15 Oct 2005 02:49:41 -0000    1.190
--- src/include/c.h    5 Dec 2005 22:39:47 -0000
***************
*** 96,101 ****
--- 96,122 ----

  #ifdef ENABLE_NLS
  #include <libintl.h>
+ #ifdef WIN32
+ #ifdef USE_SNPRINTF
+
+ #ifdef printf
+ #undef printf
+ #endif
+ #ifdef fprintf
+ #undef fprintf
+ #endif
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+
+ #endif
+ #endif
  #else
  #define gettext(x) (x)
  #endif
Index: src/interfaces/ecpg/ecpglib/Makefile
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/Makefile,v
retrieving revision 1.33
diff -c -r1.33 Makefile
*** src/interfaces/ecpg/ecpglib/Makefile    14 Mar 2005 17:27:50 -0000    1.33
--- src/interfaces/ecpg/ecpglib/Makefile    5 Dec 2005 22:39:48 -0000
***************
*** 33,38 ****
--- 33,40 ----
  ifeq ($(PORTNAME), win32)
  # Link to shfolder.dll instead of shell32.dll
  SHLIB_LINK += -lshfolder
+ # and use our snprintf
+ OBJS += snprintf.o
  endif

  all: all-lib
***************
*** 51,56 ****
--- 53,61 ----
  exec.c: % : $(top_srcdir)/src/port/%
      rm -f $@ && $(LN_S) $< .

+ snprintf.c: % : $(top_srcdir)/src/port/%
+     rm -f $@ && $(LN_S) $< .
+
  path.o: path.c $(top_builddir)/src/port/pg_config_paths.h

  $(top_builddir)/src/port/pg_config_paths.h:
Index: src/interfaces/ecpg/pgtypeslib/extern.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/extern.h,v
retrieving revision 1.7
diff -c -r1.7 extern.h
*** src/interfaces/ecpg/pgtypeslib/extern.h    15 Oct 2005 02:49:47 -0000    1.7
--- src/interfaces/ecpg/pgtypeslib/extern.h    5 Dec 2005 22:39:49 -0000
***************
*** 1,6 ****
--- 1,14 ----
  #ifndef __PGTYPES_COMMON_H__
  #define __PGTYPES_COMMON_H__

+
+ #ifdef sprintf
+ #undef sprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
+
  #include "pgtypes_error.h"

  /* These are the constants that decide which printf() format we'll use in
Index: src/interfaces/libpq/win32.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/win32.h,v
retrieving revision 1.27
diff -c -r1.27 win32.h
*** src/interfaces/libpq/win32.h    31 Jul 2004 06:19:23 -0000    1.27
--- src/interfaces/libpq/win32.h    5 Dec 2005 22:39:49 -0000
***************
*** 16,21 ****
--- 16,27 ----
  #define write(a,b,c) _write(a,b,c)
  #endif

+ #ifdef vsnprintf
+ #undef vsnprintf
+ #endif
+ #ifdef snprintf
+ #undef snprintf
+ #endif
  #define vsnprintf(a,b,c,d) _vsnprintf(a,b,c,d)
  #define snprintf _snprintf


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Andrew Dunstan
Дата:

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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




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

От
Bruce Momjian
Дата:
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
 


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Andrew Dunstan
Дата:

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


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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


Re: [PATCHES] snprintf() argument reordering not working under Windows in 8.1

От
Nicolai Tufar
Дата:
2005/12/4, Andrew Dunstan <andrew@dunslane.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
>


Re: [PATCHES] snprintf() argument reordering not working under Windows in 8.1

От
Nicolai Tufar
Дата:
2005/12/6, Nicolai Tufar <ntufar@gmail.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


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

От
Andrew Dunstan
Дата:

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




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

От
Tom Lane
Дата:
Andrew Dunstan <andrew@dunslane.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


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

От
Andrew Dunstan
Дата:

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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


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

От
Andrew Dunstan
Дата:

Andrew Dunstan wrote:

> Tom Lane wrote:
>
>> Andrew Dunstan <andrew@dunslane.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




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

От
Andrew Dunstan
Дата:

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