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
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
Bruce Momjian 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 replaced by X2 but th
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
Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> 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
Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> 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 for your next patc
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
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.
Under win32 I am sti
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
Bruce Momjian 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
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian 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 tool
Bruce Momjian 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 need
to make it happen
Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
> 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 c
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
> wrote:
> > > The CVS-tip impleme
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
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 replacem
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > >> I'm not sure that macros can have variable number of arguments on all
> > >> supported platforms. I've been burnt by this before.
> >
> > > The actual patch is:
> >
> > > + #ifdef __GNUC__
> > > + #define vsnprintf(.
Tom Lane wrote:
> Bruce Momjian writes:
> >> I'm not sure that macros can have variable number of arguments on all
> >> supported platforms. I've been burnt by this before.
>
> > The actual patch is:
>
> > + #ifdef __GNUC__
> > + #define vsnprintf(...)pg_vsnprintf(__VA_ARGS
Bruce Momjian writes:
>> I'm not sure that macros can have variable number of arguments on all
>> supported platforms. I've been burnt by this before.
> The actual patch is:
> + #ifdef __GNUC__
> + #define vsnprintf(...)pg_vsnprintf(__VA_ARGS__)
> + #define snpr
[EMAIL PROTECTED] wrote:
> > 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 macr
> 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
>> Windo
Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
> 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 beca
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 nee
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 i
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
-
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
> in
[EMAIL PROTECTED] wrote:
> > Tom Lane wrote:
> >> Bruce Momjian 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 b
[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.
> Tom Lane wrote:
>> Bruce Momjian 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 exp
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 applications.
The CVS-tip
On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
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 snprintf will
> not be expo
Nicolai Tufar wrote:
> On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
> 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
On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
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 much effort. I wo
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 g
>From what I recall from the conversation, I would say rename the vsprintf
and the sprintf functions in postgres to pq_vsnprintf and pq_snprintf.
Define a couple macros: (in some common header, pqprintf.h?)
#define snprintf pq_snprintf
#define vsnprintf pq_snprintf
Then just maintain the postgres
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 __XXtoa
Tom Lane wrote:
> Bruce Momjian 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 t
> Bruce Momjian 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 the 64-b
Bruce Momjian 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 the 64-bit speci
>
> Yes, strangly the Window's linker is fine because libpqdll.def defines
> what symbols are exported. I don't think Unix has that capability.
A non-static "public" function in a Windows DLL is not available for
dynamic linking unless explicitly declared as dll export. This behavior is
completel
Tom Lane wrote:
> Bruce Momjian 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 is 100% up to
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
> http://www.freebsd.org/cgi/man.cgi?query=snprintf&apropos=0&sektion=3&manpa
On Tue, 1 Mar 2005 16:20:50 -0500 (EST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> 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?
Defenitely not. I checked it by placing
[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 ...
> 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:
> snpr
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$
>> 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 anyo
> 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 o
[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. s
> 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.
>
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
wrote:
> Nicolai Tufar wrote:
> > On Tue, 1 Mar 2005 00:55:
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
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 :(
> >
52 matches
Mail list logo
