On Fri, Feb/ 2/07 11:20:07PM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
> >> I wouldn't really have expected that to happen on any *BSD, but you
> >> could look into the generated Makefile.global to find out.
>
> > I don't se
Kate F <[EMAIL PROTECTED]> writes:
> On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
>> I wouldn't really have expected that to happen on any *BSD, but you
>> could look into the generated Makefile.global to find out.
> I don't see anything that looks relevant for my Makefile.global; I
> would
On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > ... does PostgreSQL replace my system's snprintf() prototype with
> > its own implementation's?
>
> We do on some platforms where configure decides the system version
> is deficient ... I don't recall the
Kate F <[EMAIL PROTECTED]> writes:
> ... does PostgreSQL replace my system's snprintf() prototype with
> its own implementation's?
We do on some platforms where configure decides the system version
is deficient ... I don't recall the exact conditions at the moment.
I wouldn't really have expected
>
> 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 sep
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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.
> >
> > Fasci
Tom Lane wrote:
> Bruce Momjian 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 fi
Bruce Momjian 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 allocations now.
Tom Lane wrote:
> Bruce Momjian 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 be
Tom Lane wrote:
> Bruce Momjian 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 printf format allo
Bruce Momjian 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 the
routines were all
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
v
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
>
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
[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.
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 buf[1024];
> 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
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 Hagand
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
19 matches
Mail list logo
