Stephen Kogge <stevek@uimage.com> wrote (quite some time ago):
> In short Sun's libc does not allow 64 bit I/O (*print* functions)
> and atol does not detect overflow. When the regression tests are run
> several tests fail due to the 64 bit I/O problems. gcc does the internal
> operations but can't print :-( I will be happy if someone can tell me that
> with the sunos libc this can be done.
I have just rejiggered the int8 support so that it only depends on
snprintf instead of sprintf and sscanf. The interesting thing about
this is that we have our own version of snprintf that we use if the
platform's C library hasn't got snprintf/vsnprintf --- and our version
knows about %lld. So if you have a compiler that offers working 64-bit
arithmetic, you don't need any help from the C library to make int8 go.
I've verified that int8 now passes regression test on HPUX 9.* with gcc
--- and configure's 64-bit arithmetic check passes with HP's cc too,
so I bet that that case works as well, but I haven't bothered to run it
through regression yet.
SunOS 4.1.* doesn't have snprintf either, so int8 should work there too
as long as you build with gcc. I don't have the time to try that right
now; do you want to?
We could conceivably extend configure so that if you have working 64-bit
arithmetic but the platform's C library supplies non-long-long-aware
snprintf and vsnprintf, configure would reject those routines and use
our own. Right at the moment I'm not aware of any platforms fitting
that combination of circumstances, so I have not bothered to add the
extra complexity to configure. (Anyone who does run into this
combination can change the configuration results by hand, of course.)
regards, tom lane