Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure /configure.in...)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure /configure.in...) |
| Дата | |
| Msg-id | 16645.1043805058@sss.pgh.pa.us обсуждение |
| Ответы |
Re: Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure
|
| Список | pgsql-hackers |
petere@postgresql.org (Peter Eisentraut - PostgreSQL) writes:
> The code that checks for the 64-bit int type now gives more reasonable
> results when cross-compiling: In that case we just take the compiler's
> information and trust that the arithmetic works. Disabling int64 is too
> pessimistic.
It's not so much that we can't trust the arithmetic as that we shouldn't
trust that the platform's s(n)printf supports int64. This situation
used to be a reality on older machines with gcc but no int64 type in the
native compiler, and I suspect there are still some of them out there.
I think a reasonable choice in cross-compiling situations would be to
assume int64 works if we have a long long int datatype, but to force use
of our own snprintf rather than trusting to luck with the platform's.
(It didn't look like that's what happens right now, but I might be
missing something in the autoconf spaghetti.)
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера