Re: [pgsql-hackers-win32] snprintf causes regression

> 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 any Cygwin/Ming issues?

Is this only with the new snprintf code in Win32?

Is this a problem with snprintf as implemented in src/port?

Is there a reason why we don't use the snprintf that comes with the
various C compilers?

>
>
> On Tue, 1 Mar 2005 09:29:07 -0500 (EST), Bruce Momjian
> <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
>> Nicolai Tufar wrote:
>> > 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 :(
>> >
>> > > > template1=# select * from test where x > 1000::int8;
>> > > > x
>> > > > ------------
>> > > > -869367531
>> > > > (1 row)
>> >
>> > I am not too fluent in source code, could someone
>> > point me to there actual call to snprintf() is being done
>> > when a query like this is executed. I could not find it myslef
>>
>> Sure, in src/backend/utils/adt/int8.c, there is a call in int8out():
>>
>> if ((len = snprintf(buf, MAXINT8LEN, INT64_FORMAT, val)) < 0)
>>
>> and that calls port/snprintf.c.
>>
>> I have added a puts() in snprintf.c to make sure it is getting the
>> long/long specifier.
>>
>> --
>> 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
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>