Re: Error: insufficient data in the message

Replying to Adrian because I'm not seeing some of Ranier's posts.

>On 03/18/2016 08:49 AM, Ranier VF wrote:
>
>> Would be possible, example code in C, to format BIGINT
>> param with msvc 32 bits compiler?

>> > Subject: Re: [GENERAL] Error: insufficient data in the message
>> > To: ranier_gyn(at)hotmail(dot)com
>> > From: adrian(dot)klaver(at)aklaver(dot)com
>> > Date: Fri, 18 Mar 2016 07:50:14 -0700
>> >
>> > On 03/18/2016 07:29 AM, Ranier VF wrote:
>> >
>> > Ccing list
>> > > Hi, Thank your for response.
>> > >
>> > > After hard time, find this bug.
>> > > I see that the problem is.
>> > >
>> > > length datatypes, in param[2]
>> > > field is BIGINT (postgresql)
>> > > param (num_long var) is unsigned long long (32bits)

In 32-bit versions of MSVC, "long long" is 64-bits.
Also __int64 (with 2 underscores).

>> > > params[i].data.num_ulong = htonl(params[i].data.num_ulong);

htonl and ntohl do not work on 64-bit values ... you're changing only
the low part. And I'm suprised that you didn't get a compiler warning
about this.

Windows 8 and higher offer 64-bit versions of these functions: htonll
and ntohll (spelled with an extra L), but these functions are not
available in XP or Win7.

There are portable versions available online or you can easily write
them. Depending on your platform they both should either reverse the
byte order, or do nothing: TCP's "network" order is big-endian.

The compilers in Visual Studio 2003 and up have the function
_byteswap_uint64 which will do an 8 byte reversal.

>> > > prep->bindValues[i] = (const uchar *)
>> > > &params[i].data.num_ulong;
>> > > prep->bindLengths[i] = sizeof(ulong);

Should be sizeof(ulonglong).

>> > > prep->bindFormats[i] = 1;
>> > >
>> > > This fail miserably with windows 32bits (xp, Win7).
>> > >
>> > > If change to:
>> > > prep->bindLengths[i] = 8;
>> > >
>> > > Postgresql error goes, but the wrong value is inserted.

Yes. The length needs to be 8 for a "long long" value, and the value
itself needs to be converted correctly for TCP network byte order.

I don't work directly with libpg, so I can't say if anything else is
wrong here.

Hope this helps,
George