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
The big question is why our own vsnprintf() is not being called from
snprintf() in our port file.
I have seen this problem before, well, it isn't really a problem I guess.
I'm not sure of the gcc compiler options, but
On the Microsoft compiler if you specify the option /Gy it separates
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 ...
I have some new information. If I add the attached patch to snprintf.c,
I should see see snprintf() being called printing 0, vsnprintf()
printing 1 and dopr(), 2. However, I only see 0 printing in the
server logs.
I think this means it is finding our /port/snprintf(), but when it calls
Bruce Momjian pgman@candle.pha.pa.us writes:
I think this means it is finding our /port/snprintf(), but when it calls
vsnprintf, it must be using some other version, probably the operating
system version that doesn't support %lld.
Ya know, I was wondering about that but dismissed it because
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I think this means it is finding our /port/snprintf(), but when it calls
vsnprintf, it must be using some other version, probably the operating
system version that doesn't support %lld.
I can confirm that using %I64d for the
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I think this means it is finding our /port/snprintf(), but when it calls
vsnprintf, it must be using some other version, probably the operating
system version that doesn't support %lld.
Ya know, I was wondering about that but
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Does it help if you flip the order of the snprintf and vsnprintf
functions in snprintf.c?
Yes, it fixes the problem and I have applied the reordering with a
comment.
Fascinating.
I will start working on fixing the large fmtpar
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Does it help if you flip the order of the snprintf and vsnprintf
functions in snprintf.c?
Yes, it fixes the problem and I have applied the reordering with a
comment.
Fascinating.
I will start working
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Does it help if you flip the order of the snprintf and vsnprintf
functions in snprintf.c?
Yes, it fixes the problem and I have applied the reordering with a
comment.
Nicolai Tufar wrote:
Linux and Solaris 10 x86 pass regression tests fine when I force the use of
new
snprintf(). The problem should be win32 - specific. I will
investigate it throughly
tonight. Can someone experienced in win32 what can possibly be the problem?
Yea, I am confused too
Linux and Solaris 10 x86 pass regression tests fine when I force the use of new
snprintf(). The problem should be win32 - specific. I will
investigate it throughly
tonight. Can someone experienced in win32 what can possibly be the problem?
Nick
On Sun, 27 Feb 2005 19:07:16 +0100, Magnus
Linux and Solaris 10 x86 pass regression tests fine when I force the use
of new
snprintf(). The problem should be win32 - specific. I will
investigate it throughly
tonight. Can someone experienced in win32 what can possibly be the
problem?
Do we have any idea about what format string
After some extensive debugging with Magnus's
help we finally managed to a kind of isolate the
problem. We placed snprintf.c in a separate
file, added necessary #includes and wrote
a simple main() function:
main()
{
unsigned long long ull=4567890123456789ULL;
static char
[EMAIL PROTECTED] writes:
Do we have any idea about what format string causes the regression failure?
I'll bet the problem is that configure.in is doing things in the wrong
order: it computes INT64_FORMAT against the system printf before
deciding we should use our own printf.
Neither Bruce's nor subsequent Tom's patch did not fix
the issue. The command used is:
make maintainer-clean ./configure make make install make check
It should have be fine to recompile the source code
completely. I attach the resulting config.log. May be it
will give a clue. Regression test
Nicolai Tufar wrote:
Neither Bruce's nor subsequent Tom's patch did not fix
the issue. The command used is:
make maintainer-clean ./configure make make install make check
It should have be fine to recompile the source code
completely. I attach the resulting config.log. May be it
will
Nicolai Tufar wrote:
Regression test diff is attached.
It fails on the following tests:
int8
subselect
union
sequence
It fails to display correctly number 4567890123456789.
In output is shows -869367531. Apparent overflow or
interpreting int8 as int4.
while rewriting
Bruce Momjian wrote:
I can confirm your failure in current sources on Win32:
template1=# create table test(x int8);
CREATE TABLE
template1=# insert into test values ('4567890123456789');
INSERT 17235 1
template1=# select * from test;
x
Hi!
The new snpritnf code appears not to deal with 64-bit ints. I'm getting
failures on win32 for int8 as well as all the time related tests (win32
uses int8 for tinmestamps). Removing the snprintf code and falling back
to the OS code makes everything pass again.
I would guess this affects int8
36 matches
Mail list logo
