Autoconf'd test for int64

Started by Tom Laneover 27 years ago7 messages
#1Tom Lane
tgl@sss.pgh.pa.us

Attached is a patch that uses autoconf to determine whether there is
a working 64-bit-int type available.

In playing around with it on my machine, I found that gcc provides
perfectly fine support for "long long" arithmetic ... but sprintf()
and sscanf(), which are system-supplied, don't work :-(. So the
autoconf test program does a cursory test on them too.

If we find that a lot of systems are like this, it might be worth
the trouble to implement binary<->ASCII conversion of int64 ourselves
rather than relying on sprintf/sscanf to handle the data type.

regards, tom lane

*** src/configure.in.orig	Sat Aug 15 11:52:03 1998
--- src/configure.in	Sun Aug 16 16:41:24 1998
***************
*** 522,528 ****
  #endif
  main() { double d = DBL_MIN; if (d != DBL_MIN) exit(-1); else exit(0); }],
  	AC_MSG_RESULT(yes),
! 	[AC_MSG_RESULT(no) AC_DEFINE(HAVE_DBL_MIN_PROBLEM)])
  dnl Checks for library functions.
  AC_PROG_GCC_TRADITIONAL
--- 522,604 ----
  #endif
  main() { double d = DBL_MIN; if (d != DBL_MIN) exit(-1); else exit(0); }],
  	AC_MSG_RESULT(yes),
! 	[AC_MSG_RESULT(no) AC_DEFINE(HAVE_DBL_MIN_PROBLEM)],
! 	AC_MSG_RESULT(assuming ok on target machine))
! 
! dnl Check to see if we have a working 64-bit integer type.
! AC_MSG_CHECKING(whether 'long int' is 64 bits)
! AC_TRY_RUN([#include <stdio.h>
! typedef long int int64;
! #define INT64_FORMAT "%ld"
! 
! int64 a = 20000001;
! int64 b = 40000005;
! 
! int does_int64_work()
! {
!   int64 c,d,e;
!   char buf[100];
! 
!   if (sizeof(int64) != 8)
!     return 0;			/* doesn't look like the right size */
! 
!   /* we do perfunctory checks on multiply, divide, sprintf, sscanf */
!   c = a * b;
!   sprintf(buf, INT64_FORMAT, c);
!   if (strcmp(buf, "800000140000005") != 0)
!     return 0;			/* either multiply or sprintf is busted */
!   if (sscanf(buf, INT64_FORMAT, &d) != 1)
!     return 0;
!   if (d != c)
!     return 0;
!   e = d / b;
!   if (e != a)
!     return 0;
!   return 1;
! }
! main() {
!   exit(! does_int64_work());
! }],
! 	[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_INT_64)],
! 	AC_MSG_RESULT(no),
! 	AC_MSG_RESULT(assuming not on target machine))
! 
! AC_MSG_CHECKING(whether 'long long int' is 64 bits)
! AC_TRY_RUN([#include <stdio.h>
! typedef long long int int64;
! #define INT64_FORMAT "%Ld"
! 
! int64 a = 20000001;
! int64 b = 40000005;
! 
! int does_int64_work()
! {
!   int64 c,d,e;
!   char buf[100];
! 
!   if (sizeof(int64) != 8)
!     return 0;			/* doesn't look like the right size */
! 
!   /* we do perfunctory checks on multiply, divide, sprintf, sscanf */
!   c = a * b;
!   sprintf(buf, INT64_FORMAT, c);
!   if (strcmp(buf, "800000140000005") != 0)
!     return 0;			/* either multiply or sprintf is busted */
!   if (sscanf(buf, INT64_FORMAT, &d) != 1)
!     return 0;
!   if (d != c)
!     return 0;
!   e = d / b;
!   if (e != a)
!     return 0;
!   return 1;
! }
! main() {
!   exit(! does_int64_work());
! }],
! 	[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_LONG_INT_64)],
! 	AC_MSG_RESULT(no),
! 	AC_MSG_RESULT(assuming not on target machine))
  dnl Checks for library functions.
  AC_PROG_GCC_TRADITIONAL
*** src/include/config.h.in.orig	Sat Aug 15 11:54:54 1998
--- src/include/config.h.in	Sun Aug 16 16:33:22 1998
***************
*** 219,224 ****
--- 219,230 ----
  /* Set to 1 if your DBL_MIN is problematic */
  #undef HAVE_DBL_MIN_PROBLEM
+ /* Set to 1 if type "long int" works and is 64 bits */
+ #undef HAVE_LONG_INT_64
+ 
+ /* Set to 1 if type "long long int" works and is 64 bits */
+ #undef HAVE_LONG_LONG_INT_64
+ 
  /*
   * Code below this point should not require changes
   */
*** src/include/utils/int8.h.orig	Wed Jul  8 10:10:30 1998
--- src/include/utils/int8.h	Sun Aug 16 16:37:51 1998
***************
*** 23,51 ****
  #ifndef INT8_H
  #define 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
-
-
- /*
- #if sizeof(int64) == 8
- #define HAVE_64BIT_INTS 1
#endif
- */
-

  extern int64 *int8in(char *str);
  extern char *int8out(int64 * val);
--- 23,44 ----
  #ifndef INT8_H
  #define INT8_H
! #ifdef HAVE_LONG_INT_64
! /* Plain "long int" fits, use it */
  typedef long int int64;
  #define INT64_FORMAT "%ld"
! #else
! #ifdef HAVE_LONG_LONG_INT_64
! /* We have working support for "long long int", use that */
  typedef long long int int64;
  #define INT64_FORMAT "%Ld"
  #else
+ /* Won't actually work, but fall back to long int so that int8.c compiles */
  typedef long int int64;
  #define INT64_FORMAT "%ld"
+ #define INT64_IS_BUSTED
  #endif
  #endif

extern int64 *int8in(char *str);
extern char *int8out(int64 * val);

#2Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Tom Lane (#1)
Re: [HACKERS] Autoconf'd test for int64

Attached is a patch that uses autoconf to determine whether there is
a working 64-bit-int type available.

Using autoconf for things sounds great. I've been relying on scrappy for
that stuff, and find it a mystery myself. Marc or someone, would you be
willing to write a few sentences on how to make incremental changes to
the Postgres autoconfig system? I'll put it into the Developer's Guide,
and could make a stab at using it elsewhere.

In playing around with it on my machine, I found that gcc provides
perfectly fine support for "long long" arithmetic ... but sprintf()
and sscanf(), which are system-supplied, don't work :-(. So the
autoconf test program does a cursory test on them too.

Sorry to hear the formatting routines are broken. sprintf() and sscanf()
are HP supplied? Doesn't gcc have its own library also??

If we find that a lot of systems are like this, it might be worth
the trouble to implement binary<->ASCII conversion of int64 ourselves
rather than relying on sprintf/sscanf to handle the data type.

Yuck. Whaddya mean "we"; *my* system works fine :)

- Tom

#3The Hermit Hacker
scrappy@hub.org
In reply to: Thomas G. Lockhart (#2)
Re: [HACKERS] Autoconf'd test for int64

On Sun, 16 Aug 1998, Thomas G. Lockhart wrote:

Attached is a patch that uses autoconf to determine whether there is
a working 64-bit-int type available.

Using autoconf for things sounds great. I've been relying on scrappy for
that stuff, and find it a mystery myself. Marc or someone, would you be
willing to write a few sentences on how to make incremental changes to
the Postgres autoconfig system? I'll put it into the Developer's Guide,
and could make a stab at using it elsewhere.

Sorry to say, but from my perspective as well its "funky
magic"...I cheat alot by looking at autoconf from other packages to try
and recreate what I want to do, as well as spend alot of time in the info
pages...

I don't think this is something that can be easily explained in "a
few sentences" :(

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

#4Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: The Hermit Hacker (#3)
Re: [HACKERS] Autoconf'd test for int64

Sorry to say, but from my perspective as well its "funky
magic"...
I don't think this is something that can be easily explained in "a
few sentences" :(

Well, no harm in asking :)

- Tom^H^H^HThomas

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas G. Lockhart (#4)
Re: [HACKERS] Autoconf'd test for int64

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

In playing around with it on my machine, I found that gcc provides
perfectly fine support for "long long" arithmetic ... but sprintf()
and sscanf(), which are system-supplied, don't work :-(. So the
autoconf test program does a cursory test on them too.

Sorry to hear the formatting routines are broken. sprintf() and sscanf()
are HP supplied? Doesn't gcc have its own library also??

gcc supplies low-level routines that implement doubleword arithmetic,
but it doesn't attempt to supplant the local libc.

If we find that a lot of systems are like this, it might be worth
the trouble to implement binary<->ASCII conversion of int64 ourselves
rather than relying on sprintf/sscanf to handle the data type.

Yuck. Whaddya mean "we"; *my* system works fine :)

I'm not eager to do it either --- I hope to have upgraded to HPUX 10
before I actually need to do anything with int8. I was just throwing
that idea out in case someone else needed int8 bad enough to want to
make it happen.

regards, tom lane

#6Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Tom Lane (#5)
Re: [HACKERS] Autoconf'd test for int64

I'm not eager to do it either --- I hope to have upgraded to HPUX 10
before I actually need to do anything with int8. I was just throwing
that idea out in case someone else needed int8 bad enough to want to
make it happen.

The fact that machines need to provide their own i/o means that those
relying on gcc for compiling but non-gnu i/o libraries aren't likely to
succeed on 32-bit machines without rolling your own :(

- Tom

#7Bruce Momjian
maillist@candle.pha.pa.us
In reply to: Tom Lane (#1)
Re: [HACKERS] Autoconf'd test for int64

Applied. Autoconf run.

Attached is a patch that uses autoconf to determine whether there is
a working 64-bit-int type available.

In playing around with it on my machine, I found that gcc provides
perfectly fine support for "long long" arithmetic ... but sprintf()
and sscanf(), which are system-supplied, don't work :-(. So the
autoconf test program does a cursory test on them too.

If we find that a lot of systems are like this, it might be worth
the trouble to implement binary<->ASCII conversion of int64 ourselves
rather than relying on sprintf/sscanf to handle the data type.

regards, tom lane

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)