Re: [HACKERS] int8 type -- call for porting results!

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres Hackers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] int8 type -- call for porting results!
Date: 1998-08-16 03:37:00
Message-ID: 35D653DC.193C9E02@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I implemented it on a gcc/x86/Linux machine, and we will need to
> > ensure that it works on other platforms.
> It looks pretty broken on HPUX 9.03 (PA-RISC 1.1, gcc 2.7.2.2):
> QUERY: INSERT INTO INT8_TBL
> VALUES('4567890123456789','-4567890123456789');
> QUERY: SELECT * FROM INT8_TBL;
> q1| q2
> ! ----------+----------
> 123| 456
> ! 123|-869367531
> ! -869367531| 123
> ! -869367531|-869367531
> ! -869367531| 869367531
> (5 rows)
> At a guess, something is getting cast to int32 somewhere along the
> line, or maybe the I/O conversion routines just don't work.
> Any thoughts where to look for the problem?

Sure. It will be easy to track down...

Here is the code in include/utils/int8.h:

#if defined(__alpha) || defined(PPC)
typedef long int int64;
#define INT64_FORMAT "%ld"

#elif defined(__GNUC__) && defined(i386)
typedef long long int int64;
#define INT64_FORMAT "%Ld"

#else
typedef long int int64;
#define INT64_FORMAT "%ld"
#endif

I didn't want to break everything all at once (I always prefer the slow
slide into full breakage :), so only enabled Alphas, PowerPCs (a dumb
mistake; I had thought that they were 64-bit machines), and gcc on x86
machines. Otherwise, the type gets defined as a "long int", which
probably will give you a 32-bit quantity.

OK, so GCC on 32-bit machines has a convention that "long long int" is a
64-bit quantity. On my machine there is library support for simple
64-bit integer math; we'll need to have addition, subtraction,
multiplication and division. I'll warn you that on a previous release of
gcc on my Linux box I had to poke around in obscure directories to find
the subtraction or division routine, but my more recent installations
seem to have all of the routines up in the normal places.

So, it may be sufficient for testing purposes to remove the
"&& defined(i386)" and see what you get. We can tailor the defines to
your machine later.

- Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-08-16 04:36:55 Re: [HACKERS] Regression test status (was type coersion)
Previous Message Thomas G. Lockhart 1998-08-16 03:20:19 Re: [HACKERS] geo_ops.c is broken