Re: snprintf causes regression tests to fail

[Nicolai Tufar <ntufar(at)gmail(dot)com>]

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 <ntufar(at)gmail(dot)com> 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
> >   +  If your life is a hard drive,     |  13 Roberts Road
> >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> >
> 
> 
>