Re: Beta going well - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Beta going well
Date
Msg-id Pine.LNX.4.30.0111061358200.1111-200000@peter.localdomain
Whole thread Raw
In response to Re: Beta going well  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > However I'm not sure if it's a correct solution. Problem is, AIX 5L
> > has sys/inttypes.h where int8, int16, int32 and int64 are
> > defined. Should we detect them in configure? Also, I'm afraid it would
> > break other AIX versions. Comments?
>
> Perhaps have configure test for the presence of <sys/inttypes.h>
> and then let c.h do
>
>     #ifdef HAVE_SYS_INTTYPES_H
>     #include <sys/inttypes.h>
>     #else
>     typedef signed char int8;
>     ... etc
>     #endif

This is not correct, since we don't have any portable guarantees about the
content of <sys/inttypes.h>.

The correct way would be to check for the existance of int8, int16, etc.
The Autoconf <=2.13 macros for existance of types have been deprecated in
2.50 because they're broken.  (If the type is missing the replacement type
is #define'd, not typedef'd, which is claimed to be incorrect.  I don't
know why offhand, but let's not start finding out now.)

A possible workaround until we update our Autoconf (not now) would be

AC_CHECK_SIZEOF(int8)

#if SIZEOF_INT8 == 0
typedef signed char int8;
#endif

because the sizeof check results in 0 if the type doesn't exist.

I have attached a patch to this effect which I ask the affected people to
try out.

This patch could theoretically be insufficient if 'long int' is 64 bits
but int64 exists and is actually 'long long int'.  You would probably get
warnings about mismatched printf arguments, but I don't think there would
be actual problems.

-- 
Peter Eisentraut   peter_e@gmx.net

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Beta going well
Next
From: Tom Lane
Date:
Subject: Re: Create or replace function doesn't work so well