From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Autoconf'd test for int64 |
Date: | 1998-08-16 22:20:03 |
Message-ID: | 35D75B13.F0945305@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-08-16 22:57:37 | Re: [HACKERS] Autoconf'd test for int64 |
Previous Message | Tom Lane | 1998-08-16 22:11:35 | So what is the current documentation status? |