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];
mysnprintf(buf,1024,"%lld\n",ull);
printf(buf);
}
When compiled with -D HAVE_LONG_LONG_INT_64=1
which declares long_long and ulong_long like:
typedef long long long_long;
typedef unsigned long long ulong_long;
It compiles fine and produces desired result. If not,
it produces "-869367531" as in regression tests.
Amazingly enough HAVE_LONG_LONG_INT_64 is
defined when compilation comes to src/port/snprintf.c
but the result is still wrong. I looked into configure.in
but the check for HAVE_LONG_LONG_INT_64 is too
complicated for me to understand. Bruce, could you
take a look at this? I am 90% sure it is an issue with
some configure definitions.
Best regards,
Nicolai
On Mon, 28 Feb 2005 19:58:15 +0200, Nicolai Tufar <[EMAIL PROTECTED]> 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 snprintf() I did not touch the actual functions
> that convert number to ASCII digit string. In truth, if you
> force PostgreSQL to use snprintf.c without my patch applied
> it produces the same errors.
>
> What can be wrong? GCC bug? The one I use is:
> gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
>
> Any thoughts?
>
>
> On Mon, 28 Feb 2005 09:17:20 -0500 (EST), Bruce Momjian
> <pgman@candle.pha.pa.us> wrote:
> > 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 because my BSD uses the new snprintf.c code was
> > well. Magnus, what failures are you seeing on Win32?
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pgman@candle.pha.pa.us | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> >
>
>
>
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
