Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c
От | Tom Lane |
---|---|
Тема | Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c |
Дата | |
Msg-id | 22918.985450366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > I don't see what this configure check buys us, since it does not check for > anything that's ever been reported not working. Do you think there are > platforms that have 'long long int' but no 'LL' suffix? That seems more > than unlikely. Well, I don't know. Up till yesterday I would have said that there were no compilers that violated the C specification (not to mention twenty years of traditional practice) in the handling of integral constants of varying widths. 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". Yeah, it's paranoia, but considering that the whole thing is an exercise in covering up a "shouldn't happen" compiler bug, I think paranoia is not so unreasonable. regards, tom lane
В списке pgsql-hackers по дате отправления: