Обсуждение: Re: [HACKERS] int 8 on FreeBSD
Holm Tiffe wrote:
> Hi all,
Hi, Holm,
> While compiling of 6.4.2 I've realized that int8's are not supported
> on FreeBSD by default. The Configure script looks if %ld or %lld
> will do the job but FreeBSD is using %qd as the long long int format.
> After a little fiddeling around with the configure script and
> include/utils/int8.h, I've got the int8 type working.
> Since I've read somtimes in this Mailinglists, that FreeBSD is one
> of the development platforms for PostgreSQL, I wonder why PGSQL
> doesn't support FreeBSD's own format ...
Here are the patches I've used to enable int8 support.
Since my patches modify configure.in, you'll need to install
autoconf and regenerate the configure script.
Hope this helps,
Kevin.
==============================================================
--- ./src/backend/port/snprintf.c 1998/12/25 02:20:41 64.2
+++ ./src/backend/port/snprintf.c 1999/01/19 00:37:40 64.2.1.1
@@ -49,7 +49,7 @@#include <sys/param.h>
/* IRIX doesn't do 'long long' in va_arg(), so use a typedef */
-#ifdef HAVE_LONG_LONG_INT_64
+#if defined(HAVE_LONG_INT_64) || defined(HAVE_LONG_LONG_INT) ||
defined(HAVE_QUAD_INT_64)typedef long long long_long;typedef unsigned long long ulong_long;#endif
--- ./src/include/utils/int8.h 1998/09/11 17:16:11 64.2
+++ ./src/include/utils/int8.h 1999/01/19 00:37:41 64.2.1.1
@@ -35,11 +35,18 @@
#define INT64_FORMAT "%lld"#else
+#ifdef HAVE_QUAD_INT_64
+/* We have working support for "long long", use that */
+typedef long long int64;
+
+#define INT64_FORMAT "%qd"
+#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#endif
--- ./src/include/config.h.in 1998/12/13 20:08:24 64.2
+++ ./src/include/config.h.in 1999/01/19 00:37:41 64.2.1.1
@@ -267,6 +267,9 @@/* Set to 1 if type "long long int" works and is 64 bits */#undef HAVE_LONG_LONG_INT_64
+/* Set to 1 if type "long long" works and is 64 bits */
+#undef HAVE_QUAD_INT_64
+/* Define as the base type of the last arg to accept */#undef SOCKET_SIZE_TYPE
--- ./src/configure.in 1998/12/13 20:08:20 64.2
+++ ./src/configure.in 1999/01/19 00:37:39 64.2.1.1
@@ -688,6 +688,43 @@ AC_MSG_RESULT(no), AC_MSG_RESULT(assuming not on target machine))
+AC_MSG_CHECKING(whether 'long long' is 64 bits)
+AC_TRY_RUN([#include <stdio.h>
+typedef long long int64;
+#define INT64_FORMAT "%qd"
+
+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_DEFINE(HAVE_QUAD_INT_64) AC_MSG_RESULT(yes)],
+ AC_MSG_RESULT(no),
+ AC_MSG_RESULT(assuming not on target machine))
+dnl Checks for library functions.AC_FUNC_MEMCMPAC_TYPE_SIGNAL
Kevin Lo <jwlo@ms11.hinet.net> writes:
>> While compiling of 6.4.2 I've realized that int8's are not supported
>> on FreeBSD by default. The Configure script looks if %ld or %lld
>> will do the job but FreeBSD is using %qd as the long long int format.
> Here are the patches I've used to enable int8 support.
Actually, given the way that the 6.5 sources currently stand, the right
long-term solution is to make two separate tests: (1) does the compiler
do 64-bit arithmetic correctly, and if so then (2) does snprintf have a
working format for the chosen type. If (1) passes but (2) fails we have
a fallback: enable use of our own snprintf code. When I wrote the 6.4
configure test for int8, we hadn't yet developed that fallback, so there
wasn't much point in distinguishing compiler support from library
support. But now we should.
If we do it this way then it doesn't matter a whole lot whether "%qd" is
one of the tested alternatives or not ;-).
I will pursue fixing things that way in the 6.5 sources. In the
meantime, do we want to check Kevin's fixes into REL6_4, or is adding
int8 support for more machines too low-priority to justify taking any
chance of breaking 6.4.3?
regards, tom lane
On Sun, 7 Mar 1999, Tom Lane wrote:
> I will pursue fixing things that way in the 6.5 sources. In the
> meantime, do we want to check Kevin's fixes into REL6_4, or is adding
> int8 support for more machines too low-priority to justify taking any
> chance of breaking 6.4.3?
Note that I commited int8 fixes to the v6.4.3 tree, and they are in the
current beta3 tar file...did this mid-last week...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes: > On Sun, 7 Mar 1999, Tom Lane wrote: > > > I will pursue fixing things that way in the 6.5 sources. In the > > meantime, do we want to check Kevin's fixes into REL6_4, or is adding > > int8 support for more machines too low-priority to justify taking any > > chance of breaking 6.4.3? > > Note that I commited int8 fixes to the v6.4.3 tree, and they are in the > current beta3 tar file...did this mid-last week... Did you also change the #ifdef line to include __NetBSD__ for the %qd format? At least NetBSD/i386 uses that. Alpha might not, I'm not fully certain, but I think it will work with %qd. --Michael
Try what I just commited now...its only in v6.5 sources though...
I've modified it so that it checks for use of %lld, and if that fails,
check for use of %qd, before it falls back to our homebrew snprintf...
On 7 Mar 1999, Michael Graff wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
>
> > On Sun, 7 Mar 1999, Tom Lane wrote:
> >
> > > I will pursue fixing things that way in the 6.5 sources. In the
> > > meantime, do we want to check Kevin's fixes into REL6_4, or is adding
> > > int8 support for more machines too low-priority to justify taking any
> > > chance of breaking 6.4.3?
> >
> > Note that I commited int8 fixes to the v6.4.3 tree, and they are in the
> > current beta3 tar file...did this mid-last week...
>
> Did you also change the #ifdef line to include __NetBSD__ for the %qd
> format? At least NetBSD/i386 uses that. Alpha might not, I'm not
> fully certain, but I think it will work with %qd.
>
> --Michael
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> Try what I just commited now...its only in v6.5 sources though...
> I've modified it so that it checks for use of %lld, and if that fails,
> check for use of %qd, before it falls back to our homebrew snprintf...
What I committed this afternoon will work on a %qd box, it'll just
choose to insert our homebrew snprintf instead of using the local
version.
Is it worth adding another test cycle to configure in order to use the
native snprintf on these boxes? There are not that many boxes that
use %qd; and it's not real clear that using our own snprintf is a loss
anyway.
Just my $0.02 ...
regards, tom lane
On Mon, 8 Mar 1999, Tom Lane wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > Try what I just commited now...its only in v6.5 sources though...
> > I've modified it so that it checks for use of %lld, and if that fails,
> > check for use of %qd, before it falls back to our homebrew snprintf...
>
> What I committed this afternoon will work on a %qd box, it'll just
> choose to insert our homebrew snprintf instead of using the local
> version.
>
> Is it worth adding another test cycle to configure in order to use the
> native snprintf on these boxes? There are not that many boxes that
> use %qd; and it's not real clear that using our own snprintf is a loss
> anyway.
In all cases, using a system function is preferable to a "home brew
solution"...as its then guaranteed to work, and work optimally, for that
system...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org