Re: [HACKERS] Re: Postgres for Sunos 4.1.4
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: Postgres for Sunos 4.1.4 |
Дата | |
Msg-id | 3548.918002231@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: