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.
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
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
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
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:
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
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
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
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 :(
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
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 ...
18 matches
Mail list logo
