Skip site navigation (1) Skip section navigation (2)

Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Mariano Reingart <mariano(at)nsis(dot)com(dot)ar>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: LibPqEasy, binary cursor, x86-64, fetch(int4) problem?
Date: 2006-03-06 15:35:51
Message-ID: 200603061535.k26FZpQ10019@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfaces
I am confused by your report.  I assume AMD's still have 32-bit ints, so
it seems it should match the size of int4.  Can you try using aint as a
'long' and using '%ld' to print it and see if that helps?  Are you using
some compile flag to force 64-bit ints?  If so,try using an int8 in the
query and that should work.

---------------------------------------------------------------------------

Mariano Reingart wrote:
> Hi, I recently moved a simple application from a 32bit Intel to a new AMD64 
> server (migrated from Postgres 7.2 to 8.1.2 and LibPqEasy 3.0.4), running 
> Slamd64 (Slackware port to the AMD64). Everything compiled just fine but the 
> applicattion didn't work as expected.
> When I look into the tables (with psql) I see strange values in int4 columns 
> like ( 16777216, 402653184, 1124073472, ...) instead of normal ones (1, 24, 
> 67)
> Looking at application logs I found that libpqeasy is returning bad values 
> in fetch( &int4 ) functions.
> Thinking that my code is wrong, I run pginsert example from libpgeasy and it 
> didn't work either.
> Using text cursors (not binary) and atoi() solved the problem.
> 
> Here is a sample code to reproduce the bug, adapted from 
> /libpgeasy-3.0.4/examples/pginsert.c:
> 
> #include <stdio.h>
> #include <unistd.h>
> #include "libpq-fe.h"
> #include "libpgeasy.h"
> 
> int main(void) {
>     int aint;
>     char astring[1024];
> 
>     connectdb("dbname=fichadas");
>     on_error_stop();
> 
> 
>     doquery("BEGIN WORK");
>     doquery("CREATE TABLE testfetch(aint int4)");
>     doquery("INSERT INTO testfetch (aint) VALUES ( 1 )");
> 
> 
>     /* this will print a strange number like 16777216 instead of 1: */
> 
>     doquery("DECLARE c_testfetch BINARY CURSOR FOR SELECT aint FROM 
> testfetch WHERE aint=1");
>     doquery("FETCH ALL IN c_testfetch");
> 
>     fetch(&aint);
>     printf("aint=%d\n",aint);
> 
> 
>     /* this will print a correct value: */
> 
>     doquery("DECLARE c2_testfetch CURSOR FOR SELECT aint FROM testfetch 
> WHERE aint=1");
>     doquery("FETCH ALL IN c2_testfetch");
> 
>     fetch(astring);
>     printf("atoi(astring)=%d\n",atoi(astring));
> 
>     return 0;
> }
> 
> /* ------------------------------- */
> 
> gcc -o test1 test1.c -lpgeasy
> 
> Output:
> 
> aint=16777216
> atoi(astring)=1
> 
> Hope this helps,
> Regards,
> Mariano Reingart 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

-- 
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-interfaces by date

Next:From: Christof PetigDate: 2006-03-08 15:44:49
Subject: Re: sql3types.h copyright question?
Previous:From: John DeSoiDate: 2006-03-01 13:01:25
Subject: Re: row description, protocol 3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group