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
|
Список | 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 по дате отправления: