Andrew Dunstan wrote:
After some further digging, I think we have 3 problems.
1. On Windows gettext wants to hijack printf and friends, as below. This
strikes me as rather unfriendly behaviour by a library header file.
Anyway, mercifully libintl.h is included in our source in exactly one
After some further digging, I think we have 3 problems.
1. On Windows gettext wants to hijack printf and friends, as below. This
strikes me as rather unfriendly behaviour by a library header file.
Anyway, mercifully libintl.h is included in our source in exactly one
spot, so I think the thing to
Thanks to Andrew Dunstan, I found the cause of these link errors.
Andrew found this in libintl:
#undef snprintf
#define snprintf libintl_snprintf
extern int snprintf (char *, size_t, const char *, ...);
What is happening is that we do:
#define snprintf
Bruce Momjian pgman@candle.pha.pa.us writes:
so the effect is:
#define pg_snprintf libintl_snprintf
That's not how CPP works.
In fact, in this example, the system complains about a missing X3 symbol:
#define X1 X2
#define X2 X3
In this case any occurrence of X1
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
I have applied a modified version of your patch, attached.
I am so sorry, I sent untested patch again. Thank you very
much for patience in fixing it. The patch looks perfectly
fine and works under Solaris.
Nicolai Tufar wrote:
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
I have applied a modified version of your patch, attached.
Here is a patch that fixes the %*$ case.
FYI, I am going to pgindent snprintf.c to make it consistent so please
us CVS
I have applied a modified version of your patch, attached.
initdb will not work without %*s support, so I had to add that. Please
look over my work. I don't think i handle %*1$ but I am not even sure
what that means or if our translators would ever use such a thing. You
can probably test that
Nicolai Tufar wrote:
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace
Bruce Momjian pgman@candle.pha.pa.us writes:
I am wondering if we should just process long long args and %$ args,
and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't provide the tools you
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I am wondering if we should just process long long args and %$ args,
and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't
Bruce Momjian pgman@candle.pha.pa.us writes:
Is there no way to create a va_arg va_list structure in C?
Exactly. The standard lets you *read out* from such a structure,
but there's no provision for creating one on-the-fly.
regards, tom lane
Resubmission of yesterday's patch so that it would
cont conflict with Bruce's cvs commit. Pleas apply.
Best regards,
Nicolai.
On Sat, 12 Mar 2005 01:58:15 +0200, Nicolai Tufar [EMAIL PROTECTED] wrote:
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Please see my posting about using a macro for snprintf.
Wasn't the issue about odd behavior of the Win32 linker choosing the wrong
vnsprintf?
You're right, the point about the macro was to avoid linker weirdness on
Windows. We need to do that
Nicolai Tufar wrote:
On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Please see my posting about using a macro for snprintf. If the current
implementation of snprintf is enough for our existing translation users
we probably don't need to add anything
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace it. If we can't find a
On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
What do you think about it? Shall I abandon FreeBSD and go ahead
Incorporating Trio?
Yes, maybe just add the proper %$ handling from Trio to what we have
now.
Adding proper %$ from Trio will require too
Nicolai Tufar wrote:
On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
What do you think about it? Shall I abandon FreeBSD and go ahead
Incorporating Trio?
Yes, maybe just add the proper %$ handling from Trio to what we have
now.
Adding proper
On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Please see my posting about using a macro for snprintf. If the current
implementation of snprintf is enough for our existing translation users
we probably don't need to add anything more to it because
Bruce Momjian pgman@candle.pha.pa.us writes:
Please see my posting about using a macro for snprintf. If the current
implementation of snprintf is enough for our existing translation users
we probably don't need to add anything more to it because snprintf will
not be exported to client
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Please see my posting about using a macro for snprintf. If the current
implementation of snprintf is enough for our existing translation users
we probably don't need to add anything more to it because snprintf will
not be
[EMAIL PROTECTED] writes:
Please see my posting about using a macro for snprintf.
Wasn't the issue about odd behavior of the Win32 linker choosing the wrong
vnsprintf?
You're right, the point about the macro was to avoid linker weirdness on
Windows. We need to do that part in any case. I
Tom Lane wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace it. If we can't find a
usable replacement then we're going to have to put a lot of effort
into
Nicolai Tufar [EMAIL PROTECTED] writes:
Very well, I too, tend to think that importing some else's solution
is the way to go. Tom, have you looked at Trio?
I have not seen it ... but if it looks reasonable to you, have a go
at it.
regards, tom lane
On Fri, 11 Mar 2005 01:14:31 -0500, Tom Lane wrote:
Nicolai Tufar [EMAIL PROTECTED] writes:
Very well, I too, tend to think that importing some else's solution
is the way to go. Tom, have you looked at Trio?
I have not seen it ... but if it looks reasonable to you, have a go
at it.
It
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa and a half
a dozen
Nicolai Tufar wrote:
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa
On Wed, 2 Mar 2005 09:24:32 +0100, Joerg Hessdoerfer
[EMAIL PROTECTED] wrote:
don't know if PG borrowed the code from here, but according to the manpage
FreeBSD 5.3 seems to have a quite complete implementation, see
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Have we considered what is going to happen to applications when they use
our snprintf instead of the one from the operating system?
Hmm ...
First line of thought: we surely must not insert a snprintf into
libpq.so unless it
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
First line of thought: we surely must not insert a snprintf into
libpq.so unless it is 100% up to spec *and* has no performance issues
... neither of which can be claimed of the CVS-tip version.
Agreed, and we have to support all
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
First line of thought: we surely must not insert a snprintf into
libpq.so unless it is 100% up to spec *and* has no performance issues
... neither of which can be claimed of the CVS-tip version.
Agreed, and
On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
My next guess
is that Win32 isn't handling va_arg(..., long long int) properly.
I am trying various combination of number and types
of parameters in my test program and everything prints fine.
When it comes to pg, it fails :(
Nicolai Tufar wrote:
On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
My next guess
is that Win32 isn't handling va_arg(..., long long int) properly.
I am trying various combination of number and types
of parameters in my test program and everything prints fine.
When it comes
I spent all day debugging it. Still have absolutely
no idea what could possibly go wrong. Does
anyone have a slightest clue what can it be and
why it manifests itself only on win32?
On Tue, 1 Mar 2005 09:29:07 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Nicolai Tufar wrote:
On
[EMAIL PROTECTED] writes:
Just a question, and don't mind me if I am being rude, isn't this the
WRONG PLACE for a printf function? Wouldn't an itoa function be more
efficient and be less problematic?
This particular call could be so replaced, but it wouldn't solve the
general problem.
I spent all day debugging it. Still have absolutely
no idea what could possibly go wrong. Does
anyone have a slightest clue what can it be and
why it manifests itself only on win32?
It may be that the CLIB has badly broken support for 64bit
integers on 32
bit platforms. Does anyone know of
On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Is there a reason why we don't use the snprintf that comes with the
various C compilers?
snprintf() is usually buried in OS libraries. We implement
our own snprintf to make things like this:
snprintf(buf,%2$s
[EMAIL PROTECTED] writes:
Well, here is a stupid question, do we even know which snprintf we are
using on Win32? May it be possible that we are using the MingW version
which may be broken?
The regression tests were not failing until we started using the port/
version ...
37 matches
Mail list logo
