Re: [HACKERS] Autoconf'd test for int64 - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] Autoconf'd test for int64
Date
Msg-id 35D75B13.F0945305@alumni.caltech.edu
Whole thread Raw
In response to Autoconf'd test for int64  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Autoconf'd test for int64  (The Hermit Hacker <scrappy@hub.org>)
Quick cut at an autoconf tutorial  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Autoconf'd test for int64  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: So what is the current documentation status?
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Autoconf'd test for int64