Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under Windows in 8.1
2005/12/4, Andrew Dunstan [EMAIL PROTECTED]: 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under Windows in 8.1
2005/12/6, Nicolai Tufar [EMAIL PROTECTED]: 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 06 December 2005 04:40 To: Andrew Dunstan Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Subject: Re: [PATCHES] [HACKERS] snprintf() argument reordering not working 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. http://developer.postgresql.org/~dpage/postgresql-8.1t1.zip DO NOT use in production as it got virtually no testing. I regenerated all the GUIDs, so it will install alongside an existing installation. Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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=lorisdt=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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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 - 1.461
--- configure 5 Dec 2005 18:56:04 -
***
*** 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 - 1.190
--- src/include/c.h 5 Dec 2005 18:56:23 -
***
*** 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 - 1.7
--- src/interfaces/ecpg/pgtypeslib/extern.h 5 Dec 2005 18:56:24 -
***
*** 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 - 1.138
--- src/interfaces/libpq/Makefile 5 Dec 2005 18:56:24 -
***
*** 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/' $ $@
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
-Original Message- From: Andrew Dunstan[EMAIL PROTECTED] Sent: 05/12/05 19:03:17 To: Tom Lane[EMAIL PROTECTED] Cc: Bruce Momjianpgman@candle.pha.pa.us, [EMAIL PROTECTED][EMAIL PROTECTED], [EMAIL PROTECTED][EMAIL PROTECTED], [EMAIL PROTECTED][EMAIL PROTECTED], pgsql-hackers@postgresql.orgpgsql-hackers@postgresql.org Subject: Re: [PATCHES] [HACKERS] snprintf() argument reordering not working I'm not sure I see the objection to stripping these out of the *.def files. It will be a recipe for disaster if different builds of the same dll have different exports - apps that pick up the wrong one from a shared dir for example are likely to crash at startup. We went to some effort to prevent this for 8.0, for example, by not having separate (and different) .def files for each compiler, but by building them all from exports.txt. Regards, Dave -Unmodified Original Message- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 - 1.461
--- configure 5 Dec 2005 22:22:11 -
***
*** 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 - 1.431
--- configure.in 5 Dec 2005 22:22:12 -
***
*** 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 - 1.190
--- src/include/c.h 5
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 - 1.461
--- configure 5 Dec 2005 22:39:43 -
***
*** 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 - 1.431
--- configure.in 5 Dec 2005 22:39:44 -
***
*** 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:
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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=lorisdt=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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
I did some research and can report what was happening with *printf and libintl. Basically, there are two versions of libintl. Versions before 0.13 (November 2003) use the libc version of *printf to handle printing of translation strings. Version 0.13 and after provide their own *printf functions which understand %$ functionality. The 0.13 change is: - C format strings with positions, as they arise when a translator needs to reorder a sentence, are now supported on 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 [EMAIL PROTECTED] 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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 - 1.461
--- configure 4 Dec 2005 22:56:58 -
***
*** 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 - 1.190
--- src/include/c.h 4 Dec 2005 22:57:02 -
***
*** 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 - 1.7
--- src/interfaces/ecpg/pgtypeslib/extern.h 4 Dec 2005 22:57:05 -
***
*** 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 - 1.5
--- src/interfaces/libpq/exports.txt 4 Dec 2005 22:57:06 -
***
*** 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
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 [EMAIL PROTECTED] 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, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under
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, 1) + 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
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
