Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c

Поиск
Список
Период
Сортировка
От Ian Lance Taylor
Тема Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c
Дата
Msg-id siu24ig8mb.fsf@daffy.airs.com
обсуждение исходный текст
Ответ на Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> If you look closely, the configure test is not simply checking whether
> LL is accepted, it is checking whether we can construct an acceptable
> constant by macroized token-pasting.  That's a slightly larger
> assumption, but it's the one the code must actually make to cover
> AIX's problem.  As I remarked before, I think that ## is more typically
> used to paste identifiers and strings together; I don't really want to
> bet that pasting 0xNNN ## LL will work on every compiler.
> 
> Mainly it's a schedule-driven thing.  I don't want to take any risk that
> a last-minute patch to work around AIX's broken compiler will break any
> other platforms.  If we had found this problem before beta cycle
> started, I would be more willing to say "let's try it and find out
> whether it works everywhere".

A safe way to construct a long long constant is to do it using an
expression:   ((((uint64) 0xdeadbeef) << 32) | (uint64) 0xfeedface)
It's awkward, obviously, but it works with any compiler.

Ian


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Call for platforms
Следующее
От: Tom Lane
Дата:
Сообщение: Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c